In article <J2cM7.46373$RG1.23988812 / news1.rdc1.sfba.home.com>, David
Simmons <david.simmons / smallscript.com> wrote:

> "Doc O'Leary" <droleary / subsume.com> wrote in message
> news:251120011105195454%droleary / subsume.com...
> > In article <Su_L7.44988$RG1.23138548 / news1.rdc1.sfba.home.com>, David
> > Simmons <david.simmons / smallscript.com> 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.