2017-03-03 3:15 GMT+01:00 Chris Muller <asqueaker at 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.