First off let me say thank you Dan.  I like it, I like it a lot.

>Dan,
>
>What a beautiful outline! Here are a few comments:
>
>> Packages as Classes
>> --------------------
>
>I like the idea of having a direct message of the form 'Package Thing' very
>much, mainly because it perfectly fits the messaging idea of Smalltalk
>(regardless of their actual implementation). One thing that I would like to
>consider is having the ability of 'public exports'. What I mean by this is
>that in many packages you will have classes that are intended to be used
>from the outside and several that are more or less support classes and as
>such are generally not intended to be used from the outside. As an example
>from the 3D subsystem, the actual front end that *should* be used is the
>B3DRenderEngine and classes that generally shouldn't be used are the
>transformers, shaders, clippers, and rasterizers. I would like to have the
>ability to control what is seen as a 'public export' and still maintaining
>the possibility of getting to internals if that is really required. One way
>to do this would be to have both, 'Package Thing' and 'Package #at: Thing'.
>The first could be the public export; e.g., if you go into a browser to see
>what a package exports you look at the set of messages this package defines.
>This would be a concise set of classes which also guide the use of the
>package (use everything you see publicly but be aware of using any classes
>that are not publicly exported) while still allowing to have access to all
>classes in a package if required.
>

I like this idea too.

>> Subclassing
>> ----------------
>[...]
>> Another issue is whether a class should hold back pointers to 
>> all its subclasses.  This has bothered me ever since it was 
>> put into Smalltalk-80 (I didn't do it).  It makes it much 
>> harder to import a project, and then just forcibly delete it. 
>>  I guess one could use weak pointers here, but I wonder if no 
>> pointers might not be just as good a solution.  The subclass 
>> pointers are not frequently needed and, when they are, all 
>> you have to do is to enumerate the classes to reconstruct the data.
>
>I'd love to get rid of the subclasses references... Though I'm somewhat
>concerned about the implications when recompiling a class. It would require
>a full object memory enumeration to find the subclasses that needs to be
>changed and this could be cumbersome (any suggestions how to solve this are
>very welcome). 


>Also, it raises the issue what happens with classes stored in
>ImageSegments. Right now we at least know that we'll have to change a class
>once it comes in again (e.g., if any of the subclasses is a root stub) but
>this would be much harder then. Unless, of course, we uniquely ID all
>classes and versions (I remember the discussion of using GUIDs lately)...
>What do other Squeakers think?!
>
>  Andreas
>


I am of course still new to Smalltalk, so please excuse any obvious mistake I'm about to
make...

Would it be possible to just have a tree as a global variable that keeps track of the
class hierarchy?  Each node would have a pointer to a class, possibly some other relevant
information (last modified, etc...), and pointers to subclass nodes.  I don't know if this
would make importing/exporting any easier, but it was the first thing to jump to mind.


One quick point (which I'm sure Dan's thought of):

If project layers are implemented, it should probably mean a major effort in terms of
"organizing" Squeak.  For instance all of the HTML specific code currently in String could
be moved to HTMLPackage String.  This is probably for the best but it will probably be a
lot of work (as a newbie I can tell you that some of the base classes like String are
almost impossible to use effectively because of all the code creep, i.e. who can find a
great method like correctAgainst: when it's buried in asIRCLowercase:'s).

Josh Flowers
AppNet Inc.
josh at i33.com

The nice thing about light is that it's so easy to see when someone shines it in your
eyes. - recently inspired