Quick recap of proposal (was Re: A little namespace "proposal")

Lothar Schenk lothar.schenk at gmx.de
Fri Apr 9 20:03:08 UTC 2004


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.

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

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

> 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? ;-)

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

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




More information about the Squeak-dev mailing list