[ruby-talk:26833] Re: Selector Namespaces: A Standard Feature for Smalltalk?

In article <gCTM7.51664$[e-mail]>, David
Simmons <[e-mail]> wrote:

> Namespaces are just
> one small but fundamental key in the overall puzzle of the problem space(s)
> covered by my work. However, the post itself was specifically on an aspect
> of namespaces and thus it did focus entirely on that area and its potential
> value.

I figured that, which is why I also figured we weren't really
disagreeing as much as it seemed.

> The idea [I think you are alluding to] of modules and renaming/aliasing of
> classes and messages is a "namespace" system; just with a different name (no
> pun intended). The assumption that a "string of characters" is involved in
> the internals/implementation would not be correct for SmallScript's
> implementation (my work in this area) -- SmallScript/AOS actually flattens
> [and tracks] the textual-namespace view through strong-names using uuid's
> [otherwise, namespaces can be very problematic in versioning and
> refactoring].

I'm not making an assumptions on the implementation of SmallScript, or
any other language.  What I'm trying to get across is that aliasing is
fundamentally different from the way namespaces are handled for a
developer under most/all current implementations.  The problems come
about because namespaces, like the classes and methods themselves, are
choosen by the *vendor* and not the integrator/developer.  As such,
they don't really offer me any real power when I'm putting components
together.  If I have my own String class but want to integrate somebody
else's String class because it uses a character array interface, I want
to be able to refer to it as CharacterArray, not com.somevendor.String
or whatever the vendor has decided I should be calling it.  The same is
true for methods, where I have in my head and in my program the concept
of getting a character at a particular location in the array, and it
would make more sense to use a valueAtLocation method instead of the
characterAtIndex method the vendor liked.  In short, whatever the
solution is needs to put the power into the hands of the
developer/integrator to be really useful, and namespaces simply don't
do that.

> I'm with you on the design comments up to the last sentence on "silver
> bullets".  For me, the business outcome is still what ultimately matters and
> that is where I perceive we differ [I prioritize business success as being
> an essential requirement, so when hard choices must be made, it outweighs my
> strong feelings about design]. I.a., no matter how much "good design there
> is", given a complex system integration 3rd/other party issues can always
> come into play to break a design surreptitiously and heaven knows where the
> finger pointing ends -- and the clients don't care they just want a working
> solution.

Again, we mostly agree here.  The problems come from the, shall we say,
"backwash" from compromised implementation.  A wonderful design might,
for example, involve adding a method or methods to an existing class,
but the implementation might be in a language that doesn't have proper
category support, so a subclassing or some other solution might be
used.  That would be fine, but I too often see that then the
implementation language begins to impact the design until the people
designing the system are crippled by the limited abilities of some C++
grunts trying to crank out code.  Ooooo, I *hate* it when that happens! 
:-)