Hi all 

have you noticed that nobody uses anymore the companion list
modsqueak at bluefish.se

How do you want to have feedack then?

I put the complete email so that other people can follow. the key apsects
are at the bottom of this email.


on 18/9/01 7:30 pm, Henrik Gedenryd at Henrik.Gedenryd at lucs.lu.se wrote:

> danielv at netvision.net.il wrote:
> 
>> Hi Henrik,
>> A few questions about your modules system -
>> The Explorer is used extensively to browse modules. Is there a tool for
>> modifying them (to create the system refactorings)? how do you do it?
> 
> No, not yet, but drag and drop seems like an obvious function to add once
> the basics are all there and working. One could then record changes to a
> refactoring class too. But the hard work to me has seemed to be untangling
> relationships and figuring where things ought to go. Writing the code to
> make the moves is a minimal task in comparison, in my experience...
> 
>> Do you/will you support extensions (class definition is in module a,
>> additional methods for it are defined in module b)?
>> The DeltaModules class comment looks like it's supposed to allow me to
>> load code and install it (or not) separately, which is important. How
>> much of that is there?
> 
> The DeltaModules will do that, among other things, but right now the DM code
> is best regarded as a "demo".
> 
>> How does one load code from the HTTP repository? how does one put code
>> there?
> 
> That is the part where I havent done much at all, right now you can't do
> anything really, besides see the repository object build a url
> automatically. While the scheme is rather similar to SCAN, since the
> opportunity arose I added a high level of integration of the module and
> repository structures (they are identical). This could be a unique feature
> for Squeak, yielding great simplicity, so that specifying the module path,
> such as "Project Whisker" (cf. "java.lang.math") is sufficient for Squeak to
> automatically locate, download and install the entire thing from any place
> on the net. 
> 
> I am hoping for either or both of the "competing" repository authors to jump
> in (hint hint), or someone else of course. Anyone volunteering can count on
> good support from me. My idea was to start with something much simpler than
> e.g. CVS, that initially would more or less just allow us to easily share
> contributions (simple up- and downloading).
> 
> Note: Java people tend to complain loudly about problems with the classpath.
> I am somewhat familiar with the problem, but I would like to solicit
> experience with this from everyone here (or web pointers), so we can avoid
> thes issues if they might apply to us, no issue is too small if it is
> relevant. Grab this chance to complain about Java for a constructive
> purpose. :)
> 
>> Your work and the ModSqueak work seem quite similar in scope. Can you
>> comment on the differences?
> 
> While they may appear similar, if you look a little closer at
> ModSqueak/Ginsu, they are actually quite different in their approaches.
> Theirs doesn't use namespaces/modules at all (yet at least), and instead
> uses the declarative/semantic model of Team/V that Allen W-B described,
> which in its principles is very similar to how traditional compilers and dev
> tools operate. However, a closer comparison would get argumentative and I'll
> try to avoid a flame war here.

In ginsu modules exsist, modules are a code collecting and identifying
concept and not a ***scoping*** concept. I'm not sure that modules have to
be scoping. I think not in fact and that they can be introduce latter
****independently****. for example in Visualworks 3.0 you could load and
unload parcel (byte code and class-method definition with dependency and
versionning identification) and while loading a parcel you hide a method
implementation and unload unhide it. For this at the implementation level
you need a kind of namespace but the namespace there was not a scoping
language construct.

I still would like to be sure that coupling module and namespace is a good
idea. When  guys like alan knight, joseph and some others said that coupling
modules and namespace is a bad idea. I think that this is worth to look at
it twice. 

> Still, I would venture to say that the model of a commercial, in-house
> development process that those tools are built for is _very_ different from
> that of an internet-distributed, collaborative open-source project.

I work with Envy with a set of colleagues and I do not see well why this is
really different. We have a central database that everbody can access from
the internet. Then we have distributed responsibilities. When one creates a
new version of application that you depend one, you are responsible to
update you dependency and create new version and publish them. So why this
is not internet distributed, collaborative open source, because our code is
open source.......

 I think
> it was Paul who said that they are developing their solution because it is
> the kind of tool they want to use for their own work, which I respect, but
> to adapt it to the usage patterns and needs of the Squeak community would
> not be a straight-forward thing to do at all. I have explicitly taken the
> needs of the Squeak community into account, and tried to design a model that
> is specifically adapted to this, adopting the good features from the
> suggestions of people here, including from the ModSqueak/ Team/V approach.
> 

I really have the impression that there is a ***big*** miscommunication her
and I'm sad about that. I think that there is nothing in team-V/Envy like
model that prevent internet based solutions.  I do not see a real problem.

I have the impression that there are two aspects here (allen sent an email
with the same distinction)

   - one that is how do you identify versions of a group of class with
visibility checking, so this is Envy/Teamv  Applications for example with
some variations. This approach is more class-based from my perspective. We
manipulate abstractions and not instances of the classes themselves.

   - one that is more binary component oriented. We can send around living
object with their class or may be an identification of the previous
abstraction.

Then I have the impression that namespaces can or cannot be implied into
both design (I do not know the tradeoff and pitfalls). I think that this is
orthogonal.

Sorry to say that again but I do not see why a Envy/TeamV model would
prevent us to have internet base development. May be I'm blind.

What you cannot with a Envy model is passing objects in the sense of
project or imageSegment. For this you need to define what is the component
model you use, if you want to embed threads, objects fr example for having
mobile code...

Stef