The use of markup defined names comes from VB and that tradition.  While it
can make things easy for the enterprise developer that is not interested in
architecture or other software engineering issues, it can certainly create
large monoliths.

The idea that you can load a "module" and have it privately extend a shared
class is interesting.  It goes a bit against the idea of classes as the
definition of an object's behavior, but has value.  It is sort of like the
Objective-C formalism for adding methods to a class being a first class
semantic.  You define a thing like a subclass that has methods and it
extends the base class only in those applications where you include that
module.

The downside I see in having call context dependent behavior is that the
reader of the code needs to know the run-time context that will modify the
behavior of the object.  The same result can be achieved with a wrapper
object that implements the new methods, and passes on unknown methods to the
delegate.  This at least makes it clear there is behavior being introduced.
For example if two loaded modules both defined the same method differently,
things would get very confusing very quickly without a very clear way for
the reader/browser of the code to know which was being applied.

I can see the need to have methods that are defined by different authors
that happen to use the same selector, but are really different methods.  As
the size of libraries grows this is more and more likely.  I suspect that
method collision is far more likely and more of an issue than class name
collision.  Possibly what is needed is method name prefixes more than class
name prefixes?

Michael

-----Original Message-----
From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of Keith
Hodges
Sent: Friday, May 26, 2006 5:17 PM
To: The general-purpose Squeak developers list
Subject: Re: Name spaces in Spoon

The solutions discussed here only seem to solve one minor naming problem
rather than a proposal that could bring the community a powerful coding
and problem solving paradigm.

I remember Dave Simmons talking a lot about namespaces. One of the
benefits of his idea was that if namespaces apply on a per method basis
then you have a strategy for solving the fragile baseclass problem.

If you import a class or framework module or whatever into the namespace
that scopes your project and apply further methods bound to that
namespace only to fix or tweak that class, you can do whatever you need
without accidentally breaking anything for other clients of the said module.

Ruby and Javascript coders do this fixing tweaking all the time because
they know that any additions to the "environment" (I always add eachDo
iterator to Array in javascript) are limited in scope to the web page or
script that they are writing. Module/Framework writers have to think
about these things more carefully. It seems that  a most common way of
achieving this is through half decent documentation (auto generated etc)
that allows users of a framework to know what is there and what not to
step on, and their tools may warn of such things at compile/load time.
This doesnt really work for us since squeakers don't seem to bother so
much with api documentation.

I was surprised to find that Laszlo defines graphical elements using xml
and any <view id="myView"></view> such elements that have an id
attribute results in a global being defined that you can access myView.
This has to be the worst case scenario if I want to import or paste a
component from someone else that may very easily clash. So there are
still folks out there getting this really wrong.

just my 2p

Keith



	
	
		
___________________________________________________________ 
All new Yahoo! Mail "The new Interface is stunning in its simplicity and
ease of use." - PC Magazine 
http://uk.docs.yahoo.com/nowyoucan.html