(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.