Christian,

I like the suggestion of using packages. Dan's concise and clear comments on
the 'Working Together' discussion also point into that direction. However, I
don't think that it is such a good idea to be able to give methods a 'package
scope": a class/object should be an atomic entity; everything belonging to a
class/object should be defined in the same place. You cannot just rip out
parts of an object! Apart from the philosophical implications, it would not
like to do maintain software written in that way!

Also I am wondering what the great gain would be: either you are not happy
with a core class, i.e. Dictionary: in which case you should try to convince
Squeak Central, or you want a specialised Dictionary, in which case you should
subclass Dictionary.

Maybe you can clarify this?

One thing is clear: using modules/packages will complicate things: it is more
effort to create stable installation releases: every extra file needed
introduces an extra problem source. We need some sort of core class/object,
able to validate the state of the current Squeak install.

regards,

rob


Christian Brunschen wrote:

> Hi all,
>
> There appears to be much discussion going on about the Squeak image,
> code / project division, etc. I am by no means an expert in these matters,
> but I won't let that stop me from airing a few ideas that might make
> things a bit more manageable.
>
> 1: Hierarchical Packages, each offering a distinct Namespace
> ============================================================
> This is one of the things I like most about Java: knowing that, as long as
> I stay within my own package hierarchy, I can name my classes anything I
> want; there will be no collisions with pre-existing classes.
> This also means that I can mix-and-match packages from different vendors,
> without having to worry about any side effects because both packages
> happen to define a class with the same name.
>
> Now, I would like to extend this idea further: method names should _also_
> be declared within packages! This way, I woldn't even have to worry about
> additions made to existing classes, beause even if two different packages
> wanted to add a method 'foo' to Dictionary, these would in fact be two
> distinct 'foo' methods, and no clash would occur.
>
> 2: A Hierarchical 'File System' within Squeak
> =============================================
> One of the nice things about, say, Unix systems, is that there are
> well-defined places in the file system where you can find certain files -
> or in the more general case, _objects_, such as devices.
>
> A similar system in Squeak, where there would be, say, a hierarchical
> Directory structure which would contain named references to objects
> (either Classes or Instances), would make it possible to assign names
> within the directory structure to certain objects, which could then be
> referenced by those names.
>
> So? Well, this would separate implementation of the objects in question
> from how they would be found. In combination with packages as mentioned
> above, this would offer a powerful environment:
>
> Say that we specify that a certain service - 'Foo' - be available,
> implemented by an arbitrary class. A reference to this class would be
> placed ad '/Services/Foo' in the object system.
>
> Now, anyone could write a class, with an arbitrary name and
> implementation, and place a reference to that class at '/Services/Foo'.
> The class referenced by that name might be replaced, at some time, by one
> from another developer entirely.
>
> And while all this was going on, all other code in the system could just
> relax and call upon "the class at /Services/Foo" when they required the
> service 'Foo'.
>
> This concept can be even further refined, along the lines of 'search
> paths' for objects; something simple yet powerful, not unlike what Apple
> are using in Mac OS X, might be useful: named resources (applications,
> libraries, etc) are sought, in order:
>   * Below the User's home directory
>   * In the hierarchy for items installed locally on this machine
>   * In the hierarchy for items installed shared on a network of machines
>   * In the system hierarchy
> This allows system administrators and users tocustomize their environment
> without having to alter the system itself; any changes and additions can
> easily be located and, if need be, removed.
>
> Smalltalk already has an inkling of this, which could probably be used as
> a starting point - as the 'root' of this 'object system' if nothing else.
>
> A system such as this would also pave the way for a 'multi-user Squeak',
> where several different people could work independantly within the same
> Squeak image, at different time, or possibly even simultaneously, if such
> support were added to Squeak.
>
> Yes, I know that these changes all make Squeak more of an Operating System
> than just a programming environment - but Squeak already offers its own
> windowing system, so I don't really feel I'm trying to take Squeak in a
> direction it's not already going,at least somewhat. Of course, if I am
> mistaken, then please correct me.
>
> I also know that none of the ideas above are especially revolutionary -
> and that is one of the reasons why I think they migh be able to fly; the
> things I suggest above have been tested in some fashion in other systems
> and found to be useful and workable. I'm 'just' trying to create a synergy
> to create something even better in the form of the resulting combination.
>
> Best regards
>
> // Christian Brunschen

--
-_-__----__----___-----____---__-_-_-_____--___--
rob van den berg rvdberg at best.ms.philips.com
+31 40 27 62787  Philips Medical Systems, Netherlands