Namespaces (was: Re: [ANN]A plan for
ducasse at iam.unibe.ch
Sun Apr 4 11:10:42 UTC 2004
> As far as I understand this, you are essentially building what I think
> of as
> virtual images by using classboxes. Since you have to accomodate them
> a single "real" image, it follows that your development tools must be
> specially adapted to handle interoperability and noninterference issues
> within the context of one image. That's a possible benefit I see by
> such virtual images into "real" images. In principle, you should be
> able to
> navigate such an image using the traditional tools.
Yes but the granularity of classbox was at the level of class category
so this would generate a lot
of image. Alex introduced his own file format to save def+ bytecode.
but we cannot consider that
as an image. Alex transformed Comanche and seaside to be classbox aware
to learn from the experience.
> Noninterference would
> result automatically by virtue of having separate images. Version
> control and
> interoperability issues would have to be handled by additional tools
> conceptual scope would be outside of a particular image (implying a
> subsytem/package/class load and unload mechanism - a la Squat, maybe),
> making them an inter-image issue instead of an intra-image one, which
> in my
> thinking might possibly lead to a better seperation of concerns.
> But, again, I must state that I have no in-depth grasp of the
> intricacies and
> inherent difficulties in implementing such a scheme. It's just a hazy
> I'm throwing out in the hopes that it might give someone somewhere a
> new idea
> to chew on.
Alex built a dedicated browser but may be we could think to use the
same trick that andreas
did. We would have to think about it. Then what we did not yet take
into account is the impact
on the reflective api. What do you get when you do Smalltalk
allClasses, or MyClass selectors
(do you get all the selectors or all the visible selectors).
More information about the Squeak-dev