Re: Name clashes in Smalltalk

[hidden email] (Travis Griggs) wrote (abridged):
> worth it? There are two solutions. One is the automated computed
> solution. The other is the manual fix it. Would the man year(s)
> investment in having the all powerful resolving (and slower) system
> outweigh the cost of getting Cincom to just fix nextLine (I'm of the
> opinion that we did it right and Hal did it wrong). Some would argue
> though that it is worth having the system deal with this. Put your vote
> here if that's the case.

Having the system deal with it opens up extra possibilities. In
particular, it becomes possible for end-users to combine components from
different vendors. If a programmer is needed to resolve conflicts, users
can't combine components without having a programmer present.

In some internety, mobile code, /Neuromancer/ cyberspace scenarios, there
may not even be a human end-user present the first time two software
modules meet. I expect these scenarios, though rare today, will become
more important in future. This is the space in which Java is pitching.


> Harking back to the C++ namespace thing in Nevin's post (and wrapping
> this up). C++ does not allow you to extend base stuff. I've been
> getting to know STL quite a bit lately. There's this thing called a
> vector. It has a pop_back() and push_back() members (this is like
> OrderedCollection addLast: and removeLast). But they didn't provide a
> push_front() and pop_front() member. I cannot fix this.

You can use:

    template <typename T>
    void push_front( std::vector<T> &v, T &item ) {
        v.insert( v.begin(), item );
    }

or something like that. This is not a member function; you have to say
push_front( v, item ) instead of v.push_front( item ) so the syntax is
slightly different. You can write other forwarding functions so that the
same syntax can be used for members, too, if this matters.

I think Smalltalk's adding methods to base classes is the moral equivalent
of this. Or to put it another way, I think it is significant that C++
programmers have found the need to do similar things.
   
  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      [hidden email]      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

"Dave Harris" <[hidden email]> wrote in message
news:[hidden email]...
Geez, Dave. You sound like you're describing the factors that ultimately led
to the design and implementation of SmallScript's modularization of
Smalltalk <g>.

The above problem is exactly what the SmallScript module componentization
and selector namespace facilities address. I.e., allowing discrete modules
(sets of 0 or more components) be automatically loaded/unloaded in a system
without needing a programmer present to resolve conflicts.

Further noting that unlike Travis' concern that such facilities would be
"slower", it in fact leads to faster overall Smalltalk execution. I.e.,
There is no performance penalty/cost for selector namespaces or
modularization in SmallScript (vis-a-vis classic Smalltalks).

And let's not forget how much more prevalent this is within
scripting/web-centric languages where code/components are brought together
just-in-time via web based integration on both the client and the server.

-- Dave S. [www.smallscript.org]

>
>   Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
>       [hidden email]      |   And close your eyes with holy dread,
>                               |  For he on honey dew hath fed
>  http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."