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
|