That is really good.  So development is the same: build isolated modules.
But deployment is different either load the module as an isolated package or
as a subclass of another package and you get either patching a module or
running it separately.  The best part of your solution is that if the
namespace is visible then you can easily see the overrides created by a
subclassed package.  We could even allow tweaks to packages to remove
overrides to certain package methods, this could be stored as part of some
deployment descriptor.  This would allow you to publish different
integrations of a package for different purposes.  It would seem that the
visibility is key.  Then to Andreas' point: how do you enable communication
when necessary?  You use the namespace as part of the method call when
necessary.

It's something to think about.

Ron Teitelbaum


> From: Roel Wuyts
> 
> I want to try and extrapolate from the discussion and make another
> suggestion ;-)
> 
> I have the impression that the thread seems to revolve partly about
> two hidden and different assumptions (bear with me for the moment):
> - Andreas seems to be defending an 'anticipated reuse' model, where a
> module is a well-encapsulated black-box entity. Indeed, running in a
> different image ( 'classloader' :-) ) quite strongly enforces this
> encapsulation.
> . Lex seems to be more in favour of an 'unanticipated reuse' model
> where anybody can add elements.
> 
> Both models are at the extreme ends of the spectrum (more robust vs.
> more brittle, more closed vs. more extensible).
> 
> In the same vein however that object-oriented programming opened up
> black-box modules known from procedural languages (by differentiating
> two clients: the inheritor that has white-box access and the client,
> that can only call methods), I would propose to open-up the classical
> fully encapsulated solution you get with a closed module system by
> thinking about what inheritance between modules would look like.
> 
> 
> 
> > For example, a simple, yet perfectly valid answer to the problem is
> > to load different versions of modules in different images, or, even
> > more extreme, on different computers. Mind you, these modules can
> > still be enabled to interact by using the network to communicate,
> > however, for the purpose of our discussion, they *are* perfectly
> > isolated against each other. And now tell me why this is "utopian"
> > or why we shouldn't enable something like that from within Squeak
> > to minimize communication overhead and space requirements where
> > possible.
> >
> > And once we start looking at it from that angle we see that -
> > starting from perfect isolation- there are scopes at which we
> > expect modules to be isolated (across machines) and scopes at which
> > we expect them to interact (for example, inside applications). With
> > that basic model, we can explore which interactions we can enable
> > while still adhering to whatever strictness of a isolation we'd
> > like to implement. None of which is utopian, or a halting problem
> > or whatever; just deliberately chosen tradeoffs. (to come back to
> > the original thread, Java took one stand on these issues and
> > judging from the results they seem to work)
> >
> >> Also, notice that Smalltalkers just love adding methods to base
> >> classes.  Have you ever tried writing Smalltalk code without the
> >> abilitity to add anything to Object?
> >
> > Yes, I have. And if not for the need of having a very fast type
> > test (Object>>isFoo) I have rarely a need for them (and try to
> > avoid them as much as possible). Yes, there are situations in which
> > modifications to class Object can be useful, however, most of the
> > time there is no need for them and in the long term you are
> > typically better off without them than with them (partially because
> > you write your code more defensively).
> >
> > Besides, there are a few changes to the language that might
> > dramatically help with solving these issues - I have recently
> > started to think about traits in that way, e.g., to be able to
> > "import" an API that immediately delegates to some other
> > implementor (this particular thought was triggered by the
> > realization of traits being the equivalent of an #include<>
> > statement and one of useful the things that does is giving you
> > access to a name space - in which case you can say "self do: arg"
> > and the trait might map that automatically into "FooImpl for: rcvr:
> > do: arg" or so - I'm not sure where this would lead to but the
> > current uses of traits really resonate with me as solving the wrong
> > problem at the wrong time in the wrong context ... and yet, I do
> > think that there may be a pony somewhere) Unfortunately, you'd
> > still need that very fast type test and possibly also the need to
> > query for a default implementation.
> >
> > In any case, I think that the "love to adding methods" is pretty
> > much a red herring in this discussion. It is one of the possible
> > tradeoffs you can make but it is certainly not the only one. And
> > I'm sure we can find solutions for it if we put our mind to the
> > problem (as a matter of fact, Dan made at least one concrete
> > proposal towards that exact problem which wasn't exactly utopian
> > either).
> >
> > Cheers,
> >   - Andreas
> >
> >
> 
>