Name spaces in Dolphin...

Is there a plan to eventually add name space support to Dolphin Smalltalk?
As the number of different applications in my image grow I find that class
name prefixes become more important.  The problem with prefixing is that if
the prefix is too short it may not have durable long term meaning, and if it
is too long then it clutters the class name with information that is only
sometimes useful (i.e. when programming in the scope of ProgA you know that
all your reports are obviously ProgAReports).  It would seem to me that the
concept of name spaces would make things easier.

Is there a dark side to name spaces that I am missing?  If not then it would
be good to see them find there was into Dolphin eventually.

Chris

Chris,

> Is there a dark side to name spaces that I am missing?  If not then it
would
> be good to see them find there was into Dolphin eventually.

The syntax could be a problem, but, Dolphin appears to have a few hints of
messages to the rescue - look at #environment.  Maybe the idea would be that
doing nothing gets the default SmalltalkSystem, and taking some explicit
action gets another, hence a separate name space???

Java did a fairly nice job of this, but there's a part of me that would hate
to look at stuff like

    Com.JoesCode.Collections.SortedCollection size

Now it's time to stir the broth :)  If you have colliding names, why not use
the same classes?  Unit tests are supposed to make that safe, right?  I have
some real candidates for sharing classes, but have not done so, in part
because of concerns that would be eased (but not completely eliminated) by
good unit tests, and because of STB versioning.  I've gotten pretty
comfortable with the latter, but am somewhat concerned about my chances of
making multiple systems happy with old versions of lots of different
classes, especially when they are changing names and shapes as much as would
be "required" to really make it worth the effort.

It might help to have a framework for serializing basic types (that would
rarely if ever change) and allow domain classes to negotiate who reads them.
That by no means implies that I want Dolphin's binary filer to disappear -
it's great.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:bo6810$1876uu$[hidden email]...
> > Is there a dark side to name spaces that I am missing?  If not then it
> would
> > be good to see them find there was into Dolphin eventually.
>
> The syntax could be a problem, but, Dolphin appears to have a few hints of
> messages to the rescue - look at #environment.  Maybe the idea would be
that
> doing nothing gets the default SmalltalkSystem, and taking some explicit
> action gets another, hence a separate name space???
>
> Java did a fairly nice job of this, but there's a part of me that would
hate
> to look at stuff like
>
>     Com.JoesCode.Collections.SortedCollection size

Yes, I would hope that name spaces could be implemented in a relatively
non-intrusive way.

> Now it's time to stir the broth :)  If you have colliding names, why not
use
> the same classes?  Unit tests are supposed to make that safe, right?  I
have
> some real candidates for sharing classes, but have not done so, in part
> because of concerns that would be eased (but not completely eliminated) by
> good unit tests, and because of STB versioning.  I've gotten pretty
> comfortable with the latter, but am somewhat concerned about my chances of
> making multiple systems happy with old versions of lots of different
> classes, especially when they are changing names and shapes as much as
would
> be "required" to really make it worth the effort.

This is a good point, and I think we may be in the same boat there.  There
could be opportunities for greater class reuse, however I think that one has
to be careful of over-reuse. ;)  I know I don't have good unit tests for all
my code, especially for my older code.  I find that my projects evolve in
different periods of time.  If I have too many connections due to over-reuse
then anytime I modify a shared piece of code I end up having to test (and
potentially fix) more than one project that I really did not plan on
changing at that moment.  Imagine changing a shared class while working on
Project D and then having to fix and test (and maybe even make new tests
for) Projects A, B, and C.

If I can anticipate enough potential future generic use of something I will
develop it as a generic framework to be used by domain specific code.  I
like to reuse frameworks obviously.  Their functionality  tends to be
enhanced rather than changed.  Since my interface is usually well defined I
can grow it while maintaining backwards compatibility.  This is where reuse
shines.

There are also times when the need to reuse domain specific classes seems
obvious, when they really are being used the same way in another
application.  This adds a little stress burden in that I need to make sure I
don't break one program to add something to another.  However the benefit in
reduced code and symmetric functionality seems worth the little bit of extra
stress.

Another reason I sometimes avoid reuse is that I may want to experiment with
better ways of doing things, but with out risking messing things up that I
know used to work.  I am always learning and thinking about approaching
problems in new ways based on prior experience.  Code reuse can be bad if
you end up solving a problem in an inefficient way just for the sake of
reuse.

> It might help to have a framework for serializing basic types (that would
> rarely if ever change) and allow domain classes to negotiate who reads
them.
> That by no means implies that I want Dolphin's binary filer to disappear -
> it's great.

I believe we will be getting a "next generation" STB type thing in a future
version of Dolphin which may address some of these issues.  Persistent data
conversion is another obstacle to class reuse and refactoring.  Sure it is
easy to refactor classes in the development environment, but once we have an
application out in the real world and users have entered data we need to be
able to migrate that data.  Sure this can be done, but it adds an additional
cost and risk to refactoring.

Chris

"Christopher J. Demers" <[hidden email]> wrote in
message news:bo4gjj$17f6j6$[hidden email]...
> Is there a plan to eventually add name space support to Dolphin Smalltalk?
> As the number of different applications in my image grow I find that class
> name prefixes become more important.  The problem with prefixing is that
if
> the prefix is too short it may not have durable long term meaning, and if
it
> is too long then it clutters the class name with information that is only
> sometimes useful (i.e. when programming in the scope of ProgA you know
that
> all your reports are obviously ProgAReports).  It would seem to me that
the
> concept of name spaces would make things easier.
>
> Is there a dark side to name spaces that I am missing?  If not then it
would
> be good to see them find there was into Dolphin eventually.

I'm afraid there is a downside, and it is incompatibility. There is no one
standard namespace system, in fact they are all different, and often not
just in the detail. Of course you might think it extraordinary arrogance for
each and every Smalltalk vendor to invent their own preferred syntax and
semantics without consulting anyone else, but I couldn't possibly comment.

We do want to put namespaces into Dolphin (though it is unlikely we would be
able to do so in D6), and there seem to be three options:
1) Wait for a standard to emerge
2) Encourage the emergence of a standard by backing one particular system,
etc
3) Invent our own (or cherry pick)

Of course as Smalltalk vendors it is very difficult for us to avoid doing
(3) :-).

It looks as though we'll never have namespaces if we follow (1), so we are
left with (2).

I'd be interested to hear what others feel about this, and arguments for and
against the various contenders.

Regards

Blair

"Blair McGlashan" <blair@no spam object-arts.com> writes:

> ... Of course you might think it extraordinary arrogance for each
> and every Smalltalk vendor to invent their own preferred syntax and
> semantics without consulting anyone else, but I couldn't possibly
> comment.

Francis Urquhart is my hero.

> We do want to put namespaces into Dolphin (though it is unlikely we
> would be able to do so in D6), and there seem to be three options:

Just a caution (that I never tire of mentioning): Adding name spaces
to VW, in my opinion, was the proximate cause of the loss of the
refactoring browser for VW for *several years*.  Also, the "all or
nothing" name-space-based module system that Squeak was working toward
caused great hardship to Squeak's progress until some Squeak heroes
turned things around by abandoning the "all-or-nothing" module system
in favor a much less intrusive module system without name spaces.  Not
that Dolphin would suffer the same fate, but perhaps it is something
to consider.

> I'd be interested to hear what others feel about this, and arguments
> for and against the various contenders.

I personally do not see an upside to adding name spaces to Smalltalk
(perhaps it's just my lack of imagination about the benefits -- or
perhaps my overly active imagination about the risks).  So, please do
not bother adding them for *me*.  ;)


-- Frank

Blair McGlashan wrote:

> I'd be interested to hear what others feel about this, and arguments for
> and against the various contenders.

Some thoughts:

One is that I am unconvinced by the need for a namespace system for class
names.  It may be just me, but I find that as time goes on I use longer and
longer names for classes.  I find that I don't like to miss important
information out of the name, and normally the name is only used at the point
where a concrete class is instantiated, or in a 'constant' method that answers
a class, and *at those points* the fully informative name of the class is a
Good Thing.  The end result is that I don't feel I have to worry too much about
class name clashes.

OTOH, I have now been bitten twice by OA introducing new classes into the base
system with a name that I had already used, or wanted to use, for one of my
classes. The cases were 'Interactor' and 'TreeListPresenter'.  Looking back I
don't think that namespaces would really have helped much with either case.
Sure I could have published my ListTreeView (nee 'TreeListView') in a separate
namespace that didn't overlap with the OA space, but I don't think that would
have been very helpful to users of the package -- much better just to bite the
bullet and rename the classes.  The 'Interactor' case was similar -- I have a
fairly large chunk of code (about 60 classes) that provides my own rather
elaborate, pluggable, Inspector system which I've used in preference to the OA
one since about '99, and which, at the time, I was still intending to publish
as a goodie.  Those inspectors were called 'Interactors', and the word was
pervasive throughout the code -- class names, comments, variable names, method
names...  Then OA introduced the 'Interactor' class into the MVP framework.
Ouch!  But, again, namespaces wouldn't have helped much.  They would have made
it easier to move the code into the new version of Dolphin, but would have done
nothing to help with the confusion caused by the *semantic* clash -- it was no
good, I just had to change the name (a series of global substitutions in the
package files did most of the work).

Then too, I don't find the case for namespaces for classes without also scoping
selectors to be too convincing.  Method name clashes seem to be more of a
nuisance than class name clashes.  Perhaps because method names are used in a
different way from class names, and so should be terser than classnames (they
can assume more context) and so are less likely to be unique.  But the problem
with that is that I can't think of any way to do method namespaces with
semantics that aren't horribly complicated and/or arbitrary.

And I *really hate* the idea of adding complexity to Smalltalk.   Any
complexity.

Perhaps we should remember YAGNI.  The idea of namespaces (as I understand the
systems) is that the programmer writing the code does some work upfront to
ensure that name clashes cannot happen later.  I don't think that name clashes,
of the sort that could be resolved satisfactorily by namespaces, are very
common.  If that's true then YAGNI would suggest that requiring all that
upfront messing with namespaces is a mistake.

Perhaps all that's needed is for the *consumer* of a package to be able to load
it into a restricted "namespace" when necessary.  The implementation would
probably be quite similar to a full namespace system, but the idea is that it
would only be used where it was needed to avoid clashes.  Thus the normal case
would be that any class I wanted to refer to would be in the global space (just
as now) but in some rare cases I might have loaded some other party's code into
a more restricted space.  In those cases, since they would be rare, it would be
acceptable for me to be forced to use some fairly complicated expression to
refer to any of the "hidden" classes -- certainly there would be no need at all
for any new syntax.  Similarly, because it would be used only rarely, there'd
be no need for elaborate support in the IDE tools and browsers.  An important
point is that the external form of Dolphin Smalltalk code (.pac files,
fileouts, etc) would remain unchanged.  The only new thing the suggestion adds
is the option of loading code into the image in a slightly different way,
when/if we find we a need.

BTW.  Whatever form of namespaces (if any) eventually appear.  I'd like to see
the idiomatic use of expressions like
    Smalltalk at: <classname>
continue to work.  I don't think that requiring expressions like "self class
environment ..." is a very good idea.  I think it's possible to arrange that
the identifier "Smalltalk" resolves in any context to an object (not
necessarily the *same* object) that will search outwards through the nested
scopes to answer #at: (and the like), and insert new values into the innermost
scope in response to #at:put:.

    -- chris

> Perhaps all that's needed is for the *consumer* of a package to be able to
load
> it into a restricted "namespace" when necessary.  The implementation would
> probably be quite similar to a full namespace system, but the idea is that
it
> would only be used where it was needed to avoid clashes.  Thus the normal
case
> would be that any class I wanted to refer to would be in the global space
(just
> as now) but in some rare cases I might have loaded some other party's code
into
> a more restricted space.  In those cases, since they would be rare, it
would be
> acceptable for me to be forced to use some fairly complicated expression
to
> refer to any of the "hidden" classes -- certainly there would be no need
at all
> for any new syntax.  Similarly, because it would be used only rarely,
there'd
> be no need for elaborate support in the IDE tools and browsers.  An
important
> point is that the external form of Dolphin Smalltalk code (.pac files,
> fileouts, etc) would remain unchanged.  The only new thing the suggestion
adds
> is the option of loading code into the image in a slightly different way,
> when/if we find we a need.

+1

Another way would be to refactor the conflicting classes of the loaded
module on the fly to a non-clashing name.

Regarding methods (Ian brought it up), a warning on overwrite as now, BUT
also a history of the original method should be there.On uninstall all the
package related loose methods should be taken out of the method histories,
leading eventually to the original method being active again. History should
be in order of loaded packages.
(last one in hisory is active)
e.g.
History: {Dolphin.Collection>collect:}
<load package1>
History: {Dolphin.Collection>collect:  package1.Collection.collect:}
<load package2>
History: {Dolphin.Collection>collect:  package1.Collection.collect:
package2.Collection.collect:}
<unload package1>
History: {Dolphin.Collection>collect:  package2.Collection.collect:}
<unload package2>
History: {Dolphin.Collection>collect:}

Ciao

...Jochen

[hidden email] (Chris Uppal) wrote (abridged):
> But the problem with that is that I can't think of any way to do
> method namespaces with semantics that aren't horribly complicated
> and/or arbitrary.

Doesn't S# (or SmallScript, or whatever it's called) get this right?

I agree that selector namespaces are more important than class namespaces.
It'd be nice to be able to add new methods to String without fear of name
conflicts.


> Perhaps all that's needed is for the *consumer* of a package to be able
> to load it into a restricted "namespace" when necessary. The
> implementation would probably be quite similar to a full namespace
> system, but the idea is that it would only be used where it was
> needed to avoid clashes.

Wouldn't you want the package to be able to put some names into the public
namespace even when other names were in the restricted namespace?

At first sight it seems like "public" and "package-private" would be
enough, but then one package might need to use the restricted names of
another package, eg if it was an "extension" package. I think full
selector namespaces may turn out to be simpler than a
public/private/extension scheme.

In any case, asking the consumer to sort it all out means we can't very
well load classes dynamically, on an end-user's machine. I don't know
whether Dolphin's customers care about that, but it would surely preclude
the scheme being adopted as a pan-vendor standard. (Which is what an
"ideal" scheme should aim for, in my view.)

-- Dave Harris, Nottingham, UK

Frank Sergeant wrote:

While its certainly true that adding Namespaces required the RB to be
upgraded the major obstacle was getting first of all ObjectShare and
then Cincom to pay Don and John to do the work.  We spent longer
persuading management to pay for the work and negotiating for the work
to be done than we did on the work itself by a factor of about 2 to 1.
Had management been willing and able up front VW could have had a
functioning RB in the namespace system in 1 year instead of 3.

The issue was not technical.


 > Also, the "all or
I personally see them as of great benefit.  Apart from the many benefits
they bring to programming in the large there are lots of nice in the
small benefits.  e.g. playing with alternative versions of a package is
great in a namespace system because you can include two or more variants
in the same system, e.g. making tests that compare versions executed
side by side.
>
>
> -- Frank

--
_______________,,,^..^,,,____________________________
Eliot Miranda              Smalltalk - Scene not herd

Blair McGlashan wrote:

> I'm afraid there is a downside, and it is incompatibility. There is no one
> standard namespace system, in fact they are all different, and often not
> just in the detail.   ...

There is a simple workaround for class-namespaces that
works in *every* Smalltalk (and in Java too). Before
complicating things further by adding explicit class-
namespace support to a language, consider using this
design pattern:

1. Create all your classes with a suffix.
    For example I could create a new class
    called 'TransformerPANU'. It is unlikely
    that anyone would come up with the same
    name in their designs.

2. Create a method named #Transformer in your
    class(es) or superclass as:

     Transformer
      ^TransformerPANU

3. In your code, instead of accessing the global
    'TransformerPANU' directly, call:

      self Transformer.


This has the added benefit (over plain namespaces)
that you now *encapsulate* the information of which
actual object will be returned by #Transformer!

Using a method-call in this manner leads to more
cohesive, flexible, reusable code than accessing
a global directly (in several places). Remember
the Trick-of-63: Globals are BAD.

The downside is that 'self Transformer' is slightly
longer than plain 'Transformer', but that's the
price you pay for better encapsulation, and for
keeping the language & code simple and compatible
with other dialects.

-Panu Viljamaa

Dave Harris <[hidden email]> wrote in message
news:[hidden email]...
I'd say more. Selector namespaces could solve another issue in Smalltalk
environment - method overrides. Remember how it is implemented in VW.
Definitely, it adds another level of complexity to package system. Currently
Dolphin have no solution for the problem. With selector namespaces (each
package would be a separate namespace itself) the problem could be solved
automatically.
Say, you add your own method Behavior>>#MyNamesace.recompile: aSelector
To invoke the original method you write
    self #Dolphin.Base.recompile: aSelector
And import #MyNamespace into root namespace to override original method.

This solution reminds me subject-oriented programming. IMHO, Smalltalk
environments need another dimenstion to handle complexity and team work -
subjects is the way to go.
I'd recommend reading this paper -
http://citeseer.nj.nec.com/smith96simple.html

Uladzimir.

panu wrote: ====


A better pattern for this is as follows.

(1) Same as above
(2) Create methods in referring class(es):
 
category: 'accessing class'
>>transformer
           ^self class transformer

category: 'collaborators'
class>>transformer
           ^TransformerPANU

(3) In your code, always refer to
    transformer via the local method

       (self transformer) selectorWhatever


---
Advantages: Encapsulates further, as client
            doesn't need to know the class
            side methods, and referenced object
            can switch between local supplied
            (instance side answers inst var)
            and externally supplied
            (instance side forwards to class)
            without changing all the
                sendersOf:
           
            Subclasses can each independently
            choose whether to override with
            a locally supplied or an
            externally supplied object.

            Scanning the class side methods
            of a class quickly informs developers
            of collaborating classes, especially
            useful when subclassing, copying,
            or porting a class.

====
An alternate form of this pattern is:

(2') Create a mapping subclass of Object
     named the same as your suffix
     (in your case it would be
       PANU>>
     ).

    For each of your classNameWithSUFFIX classes,
    create a mapping method:

    PANU>>transformer
              ^TransformerPANU

    and in referring classes create
    this collaborator method instead:

    class>>transformer
               ^PANU transformer

---
Advantages: Entire "extension package"
            is mapped -- the mapping class
            shows which classes are in the
            "extension package", even when
            the "extension package" is a
            set of file-outs or a set
            of some other deploymentForm.

            Especially useful in environments
            with external CMS (CVS etc).

====
Regards,

-cstb

panu wrote:

> There is a simple workaround for class-namespaces that
> works in *every* Smalltalk (and in Java too). Before
> complicating things further by adding explicit class-
> namespace support to a language, consider using this
> design pattern:

An even more extreme point along the same design axis also obviates the need
for namespaces.

I recently (just for fun/interest in how it'd turn out) chose to implement a
small toy project in a style where all responsibility for creating objects (and
hence all references to classes) were the responsibility of a single
system-wide object.   That object (which was named after the system) also had
the responsibility for providing access to the several "important" objects in
the system.  I quite liked the way the code turned out, and may repeat the
experiment sometime.  I've always felt that the actual class of an object
should be seen as a private matter -- an implementation detail only -- and in
this case I was able to design the system so that it fitted properly with that
idea.  (At least from the outside, I did cheat on a few occasions in the
internals of the system).

Here's a couple of examples of how it looks from the outside:

"Music" is the name of the system, and the global that is the sole external
entrypoint.

"get/make a note of G#"
Music G sharp.
 "--> Music G sharp"

"add a minor third to a note"
Music G + Music minorThird
 "--> Music B flat"

"answer the notes in a C major scale"
Music C major notes
 "--> #(Music C Music D Music E Music F Music G Music A Music B)"

And so on.  (BTW I know nothing of music theory, so the above may be wrong --
the system was just an attempt to learn a bit of the basics of the theory by
turning it into code).  All classnames (except 'Music'), and much of the class
structure, are hidden from the external code that uses the library.  Internally
the pattern is much the same; e.g, the implementation of
MusicAbstractNote>>major which was used in the previous example:

major
    "answer a major key with ourself as tonic"
    ^ self music major withTonic: self.

    -- chris

Jochen Riekhof wrote:

> Regarding methods (Ian brought it up), a warning on overwrite as now, BUT
> also a history of the original method should be there.On uninstall all the
> package related loose methods should be taken out of the method histories,
> leading eventually to the original method being active again.

+ 1.


;-)

    -- chris

Dave Harris wrote:

> [hidden email] (Chris Uppal) wrote (abridged):
> > But the problem with that is that I can't think of any way to do
> > method namespaces with semantics that aren't horribly complicated
> > and/or arbitrary.
>
> Doesn't S# (or SmallScript, or whatever it's called) get this right?

I'm not sure.  I think I remember David Simmons explaining the way that S#
handled selectors some time ago, but I turned off after a couple of paragraphs,
thinking it was too complicated to be worthwhile.  I may have misunderstood,
but I've never gone back to look at the matter since.


> > Perhaps all that's needed is for the *consumer* of a package to be able
> > to load it into a restricted "namespace" when necessary. The
> > implementation would probably be quite similar to a full namespace
> > system, but the idea is that it would only be used where it was
> > needed to avoid clashes.
>
> Wouldn't you want the package to be able to put some names into the public
> namespace even when other names were in the restricted namespace?

Not in the way I'm seeing it.  The "package" wouldn't have anything to do with
it -- it's not in command, *I* am.  I might want to be able to do that, but
it's easy to do from outside the package.  E.g:

    Smalltalk
        at: #MyNameForSomeClass
        put: ((Namespace named: 'Odds and Ends') at: #SomeClass).

which might be (but there's no real need) abbreviated to something like:

    Namespace current
        import: #SomeClass
        from: 'Odds and Ends'
        as: #MyNameForSomeClass.


> In any case, asking the consumer to sort it all out means we can't very
> well load classes dynamically, on an end-user's machine

I don't see why not.  Loading classes dynamically has to happen under the
command of some code, and that code could import packages into restricted
namespaces as easily as it can import them into the global namespace.


> but it would surely preclude
> the scheme being adopted as a pan-vendor standard. (Which is what an
> "ideal" scheme should aim for, in my view.)

I agree that that should be the aim of an ideal scheme, but it's probably too
late for that.  For instance, I can't see VW ditching their syntax extensions
now.

I any case, the particular scheme that *I* was talking about (as opposed to the
thread in general) isn't so much an attempt to design an ideal namespace
scheme, as a way to avoid having namespaces at all.

    -- chris

Uladzimir Liashkevich wrote:

> Say, you add your own method Behavior>>#MyNamesace.recompile: aSelector
> To invoke the original method you write
>     self #Dolphin.Base.recompile: aSelector
> And import #MyNamespace into root namespace to override original method.

Please don't take this personally, but that is (to me) a good example of
exactly the kind of complexity that I'd hate to see added to Smalltalk.

*And* it requires a syntax extension.  <shudder/>


> This solution reminds me subject-oriented programming. IMHO, Smalltalk
> environments need another dimenstion to handle complexity and team work -
> subjects is the way to go.
> I'd recommend reading this paper -
> http://citeseer.nj.nec.com/smith96simple.html

Thanks for the link, it's an interesting read.

    -- chris

Uladzimir Liashkevich wrote:

You're confusing two different issues here.  Method overrides are
patches that redefine methods that need to be redefined for whatever
reason (for example, to add an item to a menu, or extend some method
that provides some global service to handle more client types, etc).
One still needs the ability to redefine methods already in the system.
The nice thing about method overrides is that unlike patches they are
removable, so they allow one to remove packages, which is not possible
with a simple patch.

Selector namespaces support adding methods such that one can guarantee
the addition will not clash with any other potential addition.  This is
an entirely different case, extremely useful but an orthogonal useful
feature independent of overrides/patches.


--
_______________,,,^..^,,,____________________________
Eliot Miranda              Smalltalk - Scene not herd

[hidden email] (Chris Uppal) wrote (abridged):
> > Wouldn't you want the package to be able to put some names into the
> > public namespace even when other names were in the restricted
> > namespace?
>
> Not in the way I'm seeing it.  The "package" wouldn't have anything to
> do with it -- it's not in command, *I* am.

I was thinking that adding extra functionality to String might be part of
the purpose of the package. The package's author ought to have a way to
indicate which methods were intended for public use, and which were not. I
don't think anyone other than the author can make that distinction,
because "public" is basically a promise from the author that it will not
change.


> which might be (but there's no real need) abbreviated to something like:
>
>     Namespace current
>         import: #SomeClass
>         from: 'Odds and Ends'
>         as: #MyNameForSomeClass.

The abbreviation is much easier to read :-)


> > In any case, asking the consumer to sort it all out means we can't
> > very well load classes dynamically, on an end-user's machine
>
> I don't see why not.  Loading classes dynamically has to happen under
> the command of some code, and that code could import packages into
> restricted namespaces as easily as it can import them into the
> global namespace.

That's true if your only supported policy is: everything is private. It
can't guess which names are intended to be available to other packages.


> I any case, the particular scheme that *I* was talking about (as
> opposed to the thread in general) isn't so much an attempt to design
> an ideal namespace scheme, as a way to avoid having namespaces at all.

To me it sounded like a very simple scheme, rather than the absence of a
scheme (which is what we have now). And I wonder whether it is simply
moving the complexity elsewhere. For example, how would the method
overrides (which Eliot mentions) work, unless there is some mechanism for
a package to make its methods callable from base-level code?

-- Dave Harris, Nottingham, UK

Eliot Miranda <[hidden email]> wrote in message
news:xJVqb.4571$[hidden email]... namespaces.
> >>It'd be nice to be able to add new methods to String without fear of
name
> >>conflicts.
> >
> >
> > I'd say more. Selector namespaces could solve another issue in Smalltalk
> > environment - method overrides. Remember how it is implemented in VW.
> > Definitely, it adds another level of complexity to package system.
Currently
> > Dolphin have no solution for the problem. With selector namespaces (each
> > package would be a separate namespace itself) the problem could be
solved
I mixed the two concepts by intent.
My idea is that the former should be avoided as much as possible while the
latter is a good alternative.
Method overrides are useful when done by original author to fix some problem
that should be visible globally. But in most cases a third-party developer
wants to extend an existing module with some new functionality that
shouldn't be visible outside some application/environment. Imagine you are
developing a new debugger trying to debug it with the old one...

Other method overrides issues:
2. May have problems with modules load order
3. Require manual editing when a new version of patched module arrives
4. Don't allow to chain calls to overriden implementations
5. Violate Open-Closed Principle

Uladzimir.

Chris Uppal <[hidden email]> wrote in message
news:3fab7347$0$111$[hidden email]...
I must say that Smalltalk already has certain complexities and non-regular
syntax extensions in addition to message send. :-)
Why not dropping some of them in exchange for selector namespaces and other
more useful concepts? ;-)

>
> > This solution reminds me subject-oriented programming. IMHO, Smalltalk
> > environments need another dimenstion to handle complexity and team
work -