Hi Lothar!

Sorry if I was coming down a bit "hard" in my previous post - I was in
"defense" mode. :)

Some comments:
Lothar Schenk <lothar.schenk at gmx.de> wrote:
> goran.krampe at bluefish.se wrote:
> 
> > Lothar Schenk <lothar.schenk at gmx.de> wrote:
> > > goran.krampe at bluefish.se wrote:
> > > > > I have a question:
> > > > >  From one method in Foo::Bar, I can refer to ZZ::X. I guess that this
> > > > > is possible
> > > > > and this is what I do not like. I'm curious to see the future.
> > > >
> > > > Why don't you like that? I mean - referencing classes in other
> > > > namespaces seems like something you would want to do, hard to get
> > > > anything done otherwise. :)
> > >
> > > Actually, I don't like this, too. My continuing reacquaintance with the
> > > Smalltalk way of object-orientedness is creating a growing suspicion that
> > > the information hiding concept embodied in the form of the class is too
> > > low-level to be of practical use for structuring complex systems with a
> > > multitude of classes. As it stands currently, I can use any class
> > > anywhere in my code and thus make everything dependent on everything, at
> > > least in principle, which is for me an analogue to spaghetti code.
> >
> > IMHO dependencies can be bad and good.
> 
> I'm not arguing against dependencies as such. I'm thinking about large-scale 
> systems with many parts and I don't think that it is a good idea to allow 
> everything to be connected to everything. You have to divide such a system up 
> into components and provide for the components to be connected in defined 
> ways. Not because there is any absolute rule that says so, but to make the 
> building of such systems manageable by creatures who can't keep track of more 
> than 5 to 7 concepts at the same time.

I agree "in principal" of course, but I view that as a different
problem. Still playing "defense" I would say that "black boxing" etc can
be done just fine using good ole objects and messages. If you really
want to isolate parts of a system from each other it is quite easy to do
so by just using a Facade pattern or whatever.

So IMHO we don't really need to introduce a new concept for that. I like
Smalltalk being small and really don't want to introduce new concepts
without really feeling we need them. Some kind of Namespace is probably
one of those things we actually *do need*.
 
> > A good dependency is *meant* to
> > be there. For example, my HttpView web framework builds on top of
> > KomHttpServer. That dependency is meant to be there so my classes refer
> > to classes in KomHttpServer. Of course, minimizing dependencies is
> > always nice - but to say that classes in namespace Foo can *never* refer
> > to classes in namespace ZZ is really weird to me.
> 
> This would be the extreme case. Don't think of it as an absolute rule. An 
> interface can be as revealing as it wants to. In the other extreme, it could 
> become totally transparent and make everything inside available without any 
> restrictions. I think what you call the "Kernel" could be a possible 
> candidate for that. I only think that total transparency as a general rule 
> leads to an unmanageable system if you exceed a certain size. Intuitively, it 
> makes sense to me that you can have greater stability if you program against 
> an interface instead of against the actual implementation, and my (mainly 
> gut) feeling is that having this only at the class level may not be enough. 
> If we have atoms, why not also have molecules?  

As I said above - if you want a molecule - just make one using a Good
Old Object. :)

To explain a bit further - the Namespace thingy we are discussing is
about resolving named objects at compile time. A component model like
you describe can easily be used at "runtime". In fact - you can come up
with different models for different apps - again just using simple
object mechanisms.

Again, this is just IMHO.

> > There are also classes in Kernel:: (<- this syntax is actually kinda
> > nice, don't you think?) that I typically use tons of! :) And writing an
> > application that uses Morphic:: would get pretty strange if you could
> > never refer to any of those classes. :)
> 
> If the interface would provide you with everything you need, would you know 
> the difference between using an actually existant class or one that you only 
> thought was there?

No, sure. But we need to be able to refer to classes in the code.
Abstraction is fine but only up to a certain point.

> > For a really scary example of what happens when people try to hide
> > dependencies *that are there for a reason*, just look at all the
> > overengineered Java frameworks out there spewing around Factories,
> > hideous if you ask me.
> 
> I don't know if my idea actually fits into the Smalltalk way of doing things, 
> but then it doesn't hurt to think a bit out of the box. Well, isn't the 
> Smalltalk crowd famous for finding elegant and simple solutions for seemingly 
> conflicting requirements? ;-)

Your idea about separating a system into parts that communicate with
each other using well defined decoupled protocols is IMHO just "sound
OO". I don't see a problem doing that now without Namespace or tomorrow
with Namespaces.

But I agree - we should think "out of the box". And I am listening. :)

> > And finally - if you think that my proposal is *changing* anything in
> > this respect - think again. My proposal will not add or remove one
> > single dependency that isn't there already! But it will make them clear
> > to us *and* it will make it easier to analyze and also refactor IMHO.
> 
> My rant wasn't meant as an argument against your proposal. It was just that 
> Stephane's remark seemed to be congruent with some things I had idly turned 
> around in my head, recently, and this seemed a good enough opportunity to 
> throw them out into the street and have them care for themselves. :))

Ok, I have responded as if it was an argument against my proposal :).
Even partly in this post - just can't stop. :)

Anyway, feel free to throw more stuff into the street. I really didn't
intend to rant or anything.

regards, Göran