2017-03-03 3:15 GMT+01:00 Chris Muller asqueaker@gmail.com:
That's a LOT of stuff! Environments provides a "trade-off" for the developer to engage in one sort of work instead of another sort of work. A sort of work unfamiliar to Smalltalkers..
[...]
It is not possible to load a version of FileSystem where FSPath is called Path into the same environment as ST80 without overwriting ST80's Path.
Unless you renamed it. I think of Berts question in the context of system configuration. Applications have code which configures the image for themself. Codifying the rename there (pre-load) means you can still always use the latest-and-greatest versions without having to do any more work than setting up Environments.
That might be true if you are developing an application as in "the thing that you want to start up an image for". But what I am currently working on is not meant to be an application in that sense, but another set of tools and a library. I expect them to be loaded to support development of other applications, not to be loaded all for themselves (as much as FileSystems is a library, from Squeak's perspective). And for a library, I do not like the idea of telling users that they must first rename some class in their system before they can safely install the library. Performing the rename silently in a pre-load script is even more offensive IHMO, see below.
Our environments support renaming, doesn't that help?
Yes, it does. What I meant is that because of this name conflict, I require another environment at all. Unless I consider it desirable to rename one of the Path classes and possibly change all the references from Path to FSPath in the loaded package. Or rename Path to St80Path and hope that nobody will ever add another method uses it under the name "Path".
If someone added a new method, your app still wouldn't be calling it unless you change it to do so..
I do not really understand. Maybe there was a misunderstanding. If my library automatically renames Path to St80Path (or forces the user to do it manually) and at a later time the user loads another package that has "Path" in some method that expects it to be the Path from ST80, the code is screwed. Sounds like a problem that Craig tries to solve with Naiad.
Name collisions are such a very-rare problem, and we're make the system more complicated in *so* many places, it really does feel like the tail wagging the dog.
I touched the system in many places, indeed, but I do not agree to have made it horribly more complex. The core of the matter is replacing the singleton "Smalltalk" or "Smalltalk globals" by references to something that is more specific to the respective context, and making sure that the context tells which more specific environment that has to be.
What does have become somewhat more complex is to think about how to correctly load code, when you develop the loading facilities. But how loading and compiling works is hardly trivial anyway. In comparison to other systems, it probably is, but not absolutely.
Environments is for developers (nerds). Although my preference is to reduce and simplify the system (by removing it altogether), I will respect developers who want to push forward as long as it is not exclusionary to power users and Smalltalk newbies, meaning it must preserve the illusion of Smalltalk-80's original, simple, single Smalltalk environment.
Programming tools are for developers. Nobody criticizes their unconditional presence, though. Environments are a tool to be used under the right circumstances, offering a way out of some tricky conflicts that arise in the real world and that developers (or nerds) need to solve.
Multiple environments simply are not the same as a single environment. To simulate the view of a monolithic environment at any time, it might help if browser & co. also showed the imported classes, not only the declared classes of an environment. But then it is imperative to indicate the environment more prominently, as Bert requested, because otherwise users might be more frequently grabbing the wrong browser window and wondering "why are my classes not here?"
If we wanted to always show all classes from all environments, each visual class reference would have to carry an environment tag, like "Path [FileSystems]" and "Path [MVC]" (could be omitted for the original Smalltalk environment). It might be distracting, though. For example when every other class in the test runner would carry a tag and you could not easily deselect or filter by tag/environment. For tools that have a category list, the tag could be added to the category instead, segregating classes in dependent list views by environment. Though, it might cause confusion about what categories are (or rather are not). You would still need the tag on the class name when no category is indicated, such as in message traces. .
What is more important and where environments are really lacking at the moment IMHO is that there is no easy or canonical way of transferring them to another image. As long as my library uses environments to deal with Path and friends, it cannot be installed by simply loading a Monticello package or configuration. Users are still burdened with setting up and organizing environments, like they would traditionally be burdened with renaming ST80's Path and remembering it when they encounter bugs in yet another package. So I agree that environments are not a finished solution and realize they are not the complete answer to the needs for a module system. But they will never become better if you cannot even work with them.
squeak-dev@lists.squeakfoundation.org