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. 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.

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. :)

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.

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.


regards, Göran

PS. Minimizing dependencies is of course nice, but I can't see exactly
what this has to do with the proposal.