[ENH][Modules] Another version

danielv at netvision.net.il danielv at netvision.net.il
Wed Sep 19 16:29:09 UTC 2001


Henrik Gedenryd <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...
Sure, I was wearing my user hat, and trying to convince myself I don't
have to do the untangling of the RB code with just the dual changeset
browser :-)

> > 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".
Yup, I read what there is about the DeltaModules. I'm a bit confused, it
seems like they're supposed to be many things at once, this looks
confusing to me, maybe I don't have the right glasses yet.

On one hand, they represent the same thing as a Module, except stored as
deltas from a specific module.
OTOH, DMs can be extensions, but Modules can't. ?!
OTGH, DMs are supposed to replace change sets, but when I make a change
set, it usually touches a few logical modules, not one. At least
eventually, it is the conjunction of deltas to several modules, not one.

Can you clarify?

I think someone (Allen) had a point when they said that change sets
serve a different purpose than modules. I think young change sets group
changes that are close in time and author (like updates). As time
passes, I refactor things into more logical, permanent groups, like a
logically coherent changeset I'd post to the list or to divisions like
categories/modules. 

I think it's important to support this form of work.

> 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. 
In the Debian way, just a module name is usually sufficient.
I'll post on that shortly. 

> 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).
I've been using SCAN to manage the RB lately, and I like it. It already
does up/down loading. It has most the right concepts (configurations,
packages, versions, dependencies), and they look right to me, but it
doesn't have much support for using information in it yet - no way to
choose a configuration, and have it's prerequisites and components
downloaded automatically.

Another hard part is to make the repository help Sunday Squeakers
contribute - we need some connection between the [ENH/FIX]es posted to
the list and their modules. The situation right now with contributors
having to push their changes over and over without much feed back and
with change reviewers having to gather and reread everything every so
often is not that great.
 
[abstract comparison of ModSqueak and Henrik's work]
Please *do* tell us more about the differences, because:
A. I'm (we're?) curious. 
B. If we understand what it's trying to do, there's more chance we'll
use it (negative example - Environments) 
C. We might have good ideas.
I'm you don't need to get into a flamewar, you followed your ideas, they
followed theirs. Probably neither is stupid.

What do you mean when you say your are/will be built for a
"internet-distributed, collaborative open-source project"?

> > BTW, in the regular browser, after loading your changes and executing
> > the refactoring, the menu for class categories (now modules?) bombs. See
> > error below.
> 
> Thanks, that was a very stupid bug.

Yes I noticed what it was later, I should have just sent a fix.

> Henrik




More information about the Squeak-dev mailing list