"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". 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. The client use of versioning would provide them with warnings
regarding the need for (possibly) updating their implementation.

That combination of continued proper behavior (and a "warning" if well
planned) [as opposed to error and failure] directly addresses the 3rd-party
late integration problem where the provider and consumer have no
pragmatic/real means of coordinating engineering designs on required
deployment timescales [or, as also occurs, involved parties may not have the
skill, training, or mechanisms to do so].

Based on that, I have to disagree with you here [selector-namespaces do
precisely address the defensive design issue where change encapsulation is
required]. Look over Waldemar's slides, my goal here was not to present a
thorough discussion on the topic of change management [I hardly have the
time]. I was answering [augmenting] the question of what are selector
namespaces and providing an example to help a Smalltalker understand the
JavaScript 2.0 references I provided.

I understand the versioning view/approach; even with versioning this
approach augments classic versioning "detect but not solve" issues and the
pragmatic chanllenges of "having multiple versions available". Use of
versioning is a more "idealistic/planned" approach and is an important part
of provider-consumer planned software engineering management in the face of
change. However, the example I gave is illustrative only and as a concocted
rewrite example [from Waldemar's talk], in which I did not also present
real-world constraints, it can readily be picked apart. One could have
argued for re-factoring; or use of the C# identify/detect (but not solve --
allow to run correctly) mechanism for declared intent regarding creating a
new message/method versus refining an existing one.

The question was not "what are the best practices" when both provider and
consumer are well coordinated [that is an old issue which we hopefully
understand], nor is it how one could "catch the problem" [i.e., with
versioning et cetera, which does not solve it it just identifies it". As I
said originally, "Waldemar's slides present discussion of the general issues
and non-solutions so I will not repeat them here."

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.

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