(cc: squeak-dev)

>> > I think the #1 thing I don't like about Environments is its viral
>> > nature to force a change to the habits of the entire community, and
>> > associated compatibility upheaval.
>>
>> Do environments actually require a change to existing code? Surely any
>> existing code would simply load into a base environment and work exactly as
>> now?
>
> Of course existing code would have to change if code it relies upon is
> changed.  For example, the Spur bootstrap does a lot of Monticello
> scripting.  If Monticello were moved into its own environment and the
> classes there-in would lose their MC prefixes then the scripts in the Spur
> bootstrap would have to change to match.  The Monticello environment would
> have to be imported and the class names changed.  But that could all be done
> automatically.  I don't see it as a problem.
>
> As far as Chris's feelings, that's an argument for complete stasis.  It
> doesn't allow us to make any fundamental changes to the language for the
> bnetter.  t is precisely because environments allow code to be modularised
> that we want it.  It is precisely because people will have to modularise
> their code that the habits of the entire community can, and should change.

The audience I want to include into the Squeak community are not just
developers but "users" too.  Few systems besides Squeak have
maintained enough restraint of features to still have that level of
approachability.  To a new user, Squeak can still say its a simple
system of just objects sending messages and nothing more.

It seems possible that Environments could interfere with that.  It
feels like a consequential solution to an inconsequential problem.
For me, a "Squeak-style" solution to the requirements we've mentioned
in this thread could be strictly met by the UI-level hack:

Requirement #1 -- must be able to resolve a name-collision between
systems, should it occur.

     We agreed that the Rewrite tool can be used to rename classes, as
it could to resolve a name-collision.

Requirement #2 -- must be able to see pretty names in the code, with
an easy way to disambiguate.

    We could add a "show prefixes" check box to the CodeEditor menu.
Checked shows the real code, unchecked renders the code with the
prefixes removed.

Requirment #3 -- must be able to type pretty names in the code, with
an easy way to disambiguate them on save.

    Nothing to do.  Squeak 4.5 already allows pretty names to be
typed.  If the user had "show prefixes" unchecked when they started
editing the method, or otherwise typed a pretty name, the system today
will prompt them for which, i.e., "Session" they meant.  The
replacment is done but then after the method is re-rendered according
to the show-prefixes setting.
--------

Does this not, in the strictest sense, meet the requirements?  This
level of functional leverage is what captured and maintained my love
for Squeak.

> I should say that our experience with VW was that we created a Smalltalk
> namespace which imported all the base namespaces so that for programmers
> that didn't reach into more exotic parts of the system there was no real
> change.  So everybody's habits don't have to change al at once.  But
> Smalltalk (the namespace) is crowded, two-letter prefixes are a hack, and
> putting things in environments is a neat and comprehensible change.  Why
> now, when we have environments in the system, are objections being raised?

The time when you created a Smalltalk namespace in VW was a different
context.  As a rising off-the-shelf commercial product with
potentially closed or copyrighted code (even from 3rd party vendors),
customers would not have the option to employ the Rewrite solution as
we do.  So a "ultimate solution" to allow any-or-all-code to coexist
with no changes had to be built.

An open-source, DIY-style system like Squeak does not bear this requirement.

> Chris, what would you do?  Rip them out?

No.  They're already there, so let's let them get tested out by
someone.  If you don't mind, I might add that "show prefixes" feature
because I DO like reading and writing pretty names sometimes, like for
teaching and demos, but I just don't see myself rewriting the entire
"Ma" stack for it.