Envy or Store or what?

Martin Kobetic kobetic at rogers.com
Mon Oct 28 22:44:41 UTC 2002


Well, I think the answer depends on your goals. CVST (I hope it's OK if I use it as a short for CVSTProj part of it in this message
:-) is aiming at:
1) merging Smalltalk with the "source tree" style of projects.
2) portable framework allowing to run a project across several dialects.

For 1) I believe that file per class is a better match. More granular history of the project allows you to answer questions like
"When was this class changed ? How many times ? ", allows rollback of individual classes, etc. Which I think are frequent enough to
warrant the support. I don't find the argument about load ordering too strong, it's a pretty trivial algorithm, since with the built
in Undeclared mechanism the class hierarchy is the only thing you really need to deal with. I admit that more frequent
adds/removes/renames are additional overhead, but that's more CVS "feature" than anything else. Better SC tool will make that
easier.

It seems to me that DVS is more focused on Squeak than on CVS and there's not as much drive to get as much out of the SC tool as you
can. In which case file per package sounds reasonable too. I suspect that both DVS and CVST have a lot in common as they both
synchronize the state in the image with the state in the source file tree (computing changes, applying them to the image or to the
files, etc). To address goal 2) CVST adds flexible source code format support (you really have to use SIF to run cross-dialect at
the moment) and explicit portability interfaces to aid porting efforts. I don't know how far is DVS in that area.

In any case DVS definitely does seem to have more drive behind it in the Squeak camp at the moment. The Squeak port of CVST is
lagging behind the VW, VA and Dolphin ports by one version at the moment (as there was no Squeak person in our group at Camp
Smalltalk 4 in Colorado) and I definitely won't have time to spend on it. Of course I am sorry to see CVST loosing in the Squeak
circles, but that's natural when a more active alternative comes in. Especially if the alternative focuses on more urgent needs of
the community.

Best regards,

Martin

Martin Kobetic, Cincom Smalltalk Development, http://www.cincom.com/smalltalk
----- Original Message -----
From: "Avi Bryant" <avi at beta4.com>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Monday, October 28, 2002 3:50 PM
Subject: Re: Envy or Store or what?



On Mon, 28 Oct 2002, [ISO-8859-1] Göran Hultgren wrote:

> What about that btw - what is your reasoning about having one file per package
> (instead of say one file per class)? It sort of "defeats" interesting properties
> in CVS I think.

But having one file per class defeats some nice properties of changesets -
they impose an order on loading in classes (so you don't define a subclass
before its superclass), they are easy to distribute and install, Squeak
automatically deals with them even when compressed, etc.

Having too many files also makes CVS unwieldy - you always have to be
doing adds and removes, revision numbers are on the class and not the
entire package, and so on.  And the major advantage - that conflicts are
kept low - is taken care of fairly well by the order in which DVS files
things out.

However, if sqcvs integration was done (so that adds and removes could be
done automatically), and using .sar as a packaging format (and generating
an install script that loaded everything in the right order), then it
might make sense to finish working on the DirectoryPackageDumper, which
files out each method and class definition as a separate file.

> And another thing, what do you think about the "decisions about how we proceed
> with modules" I have been trying to get people buzzing about?

Well, I'm personally going to continue making 3.2 the best (as defined by
"most useful to me") environment I can, without worrying for a moment
about duplicating functionality that may or may not exist in 3.3a.  Either
everyone else will make roughly the same decision, or they won't.

Avi





More information about the Squeak-dev mailing list