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

Lothar Schenk lothar.schenk at gmx.de
Fri Apr 9 11:55:34 UTC 2004


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. What I would like to see is a way to 
hide a bunch of classes behind an interface that defines collectively for 
this bunch of classes what the outside world is allowed to see or not, or 
otherwise put it defines what services these classes offer to the world as an 
agglomerate without revealing the particular implementation and thus also, as 
a default, hiding any classes contained in this bunch from the outside. For 
example, in the case of a progress notification the client application need 
have no knowledge what type of window is used or if there is any window used 
at all. In principle, Morphic could be polymorphic with MVC via the 
definition of such an interface and could also be polymorphic with a package 
that's based on simple text display entirely, e.g. a curses-like UI manager. 
No internals of Morphic or MVC need be revealed to the outside world, 
provided the service interface is defined in an implementation-independent 
way. Internals of Morphic would only be visible to someone actually in the 
process of working on the implementation of Morphic.

Here's a sketch of how this could look like to a client application:

DemoApplication>>initialize
  uiManager := self environment defaultUIManager. "Might be MorphicUIManager 
or MVCUIManager or anything else that could function as user interface"

DemoApplication>>doSomething
  "...." "do something"
  self reportProgress: xx percent.

DemoApplication>>reportProgress: aPercentvalue
  uiManager progress: aPercentvalue.
"it's the job of whatever is in uiManager to do something with aPercentvalue 
via the service 'progress:' it provides, print it in a message on the 
Transcript or display a progress bar window or whatever, DemoApplication 
doesn't care"

This is not, of course, intended as a blueprint or concrete implementation 
proposal. These are just my thoughts on how one can get anything done without 
having to know or care who actually does it. Which is my current and possibly 
very limited understanding of what information hiding and polymorphism are 
meant to achieve.

Regards, Lothar






More information about the Squeak-dev mailing list