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

Doc O'Leary,

I've read your post/response and I don't know how to respond. You seem to
think that "versioning" is the solution to all the ills when I've pointed
out issues that versioning simply doesn't address. And my posts were merely
augmenting/clarifying items relating the JavaScript 2.0 references cited in
the original post on selector-namespaces.

I've also made it abundantly clear that versioning is already a supported
language option and that the PRAGMATIC issue is that in REAL situations of
just-in-time deployment it NOT always an option. Why are you ignoring the
realities of software deployment and telling me what I already know about
the ideals of versioning.

You also prattle on about namespaces with non-specific "dogma", yet you
could not have had experience with "selector namespaces" which ARE NOT just
"namespaces" as we see in other systems. They are a NEW Unifying Feature for
Dynamic Languages that provide a more general solution to what SOME static
languages have provided in the form of "public", "private", "protected".

They are not meant to be a SUBSTITUTE or REPLACEMENT for versioning [rather
they augment it], they are designed to address REAL issues [which one can
demonstrate "versioning" does not adequately address; as per one (or more)
of my posts] in the area of effective/reliable deployment in 3rd party late
integration scenarios.

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

"Doc O'Leary" <[e-mail]> wrote in message
news:[e-mail]...
> In article <J2cM7.46373$[e-mail]>, David
> Simmons <[e-mail]> wrote:
>
> > "Doc O'Leary" <[e-mail]> wrote in message
> > news:[e-mail]...
> > > In article <Su_L7.44988$[e-mail]>, David
> > > Simmons <[e-mail]> wrote:
> > >
> > >
> > > > What we would like is some mechanism to ensure that the two
different
> > > > versions of #size remain independent. Selector namespaces directly
solve
> > > > this issue.
> > >
> > > Actually, they don't.  The real issue in this case is that a
> > > subclass/method intended for the 1.0.0.0 version of BitTracker is
being
> > > applied to the 2.0 version.  To directly address this problem, you
> > > would do something about the:
> > >
> > > Requires module: BitTracker. "version constraints elided"
> > >
> > > part of the issue.  Modern systems are already pretty good when it
> > > comes to issues of version managment.  Namespaces, as is so often the
> > > case, don't really solve the problem here and unnecessarily complicate
> > > matters.
> >
> > I think you missed the primary point -- which is solving/addressing the
> > challenges of change in the face of the pragmatic reality that
versioning is
> > not being used by the client/consumer, and/or multiple versions may not
have
> > been provided or may not have been a viable option for the "provider".
>
> If the direct problem is with versioning, the solution should deal with
> versioning.  Hacking out an unrelated solution to address the issue is
> bad design and development.
>
> > With
> > the selector-namespace approach, only the provider had to be using a
> > well-planned design approach. With the key being that whether or not the
> > client was also well planned and versioning was employed [either for
detect
> > only, or for select of an older version], their code will still continue
to
> > work.
>
> Uh, no.  By introducing namespace resolution, you have in fact moved
> the burden of "using a well-planned design approach" on to the client,
> not the provider.  The clients code will not work unless they go to
> great care to make sure proper namespaces are respected in their code.
> As a result, dependencies are scattered all throughout the code instead
> of being in one place.
>
> > The client use of versioning would provide them with warnings
> > regarding the need for (possibly) updating their implementation.
>
> An *actual* solution would be based on this, perhaps allowing the
> client to override version requirements if they *knew* dependencies
> were met for the newer version.
>
> > The exact point of this example [hence my pointing out that versioning
> > pre-requisites were elided] was that we wanted a pragmatic solution for
> > defensively encapsulating change [where multiple versions and/or version
> > based identification of the problem was not a viable option; and was not
> > being applied]. The situations where this is needed is a very common
(real)
> > deployment [just-in-time/late integration] scenario. In the face of that
> > reality, can component software and scripting solutions be built which
solve
> > the problem. The answer is yes, and the solution provided does address
the
> > issue.
>
> It addresses it improperly, as though namespaces were a silver bullet
> for all the ills of integration.  In my experience, that is not the
> case, and they in fact tend to produce code that is less coherent and
> more difficult to maintain.  Instead of waving around namespaces like
> some magic wand, please *do* be pragmatic about what the actual
> problems are and what appropriate solutions would be.  In reality,
> solutions to such problems require richer language features rather than
> simple namespaces.