[squeak-dev] Environment changes in the Inbox

Chris Muller asqueaker at gmail.com
Fri Mar 3 02:15:26 UTC 2017

I know we've already discussed it a lot in the past, but since none of
the reasoning for using Environments to solve this issue has changed,
the simpler approaches still deserve advocacy.  (Below..)

>>> My Environments use case, for which I have gone through all of this,
>>> is that I need to use and work on a Pharo package that uses the
>>> FileSystem library. The FileSystem classes have different names in
>>> Pharo, compared to the FS package available on SqueakSource.
>> Can you walk us through this use case? What tools do you use in which order?
> Well, if I were to start from scratch with my changes already in the
> image, I would do the following:
> 1. prepare the environment in a workspace, because there are no tools for it:
   ... snip...
> 2. open a Workspace that "lives" in the new environment:
> 3. in the Monticello Browser, add a working copy for the package I
> want to work on (+ Package)
> 4. right-click on it > change environment... choose my new environment
> named NewProjectWithPharoBindings.
> 5. add the appropriate repository, open it, load the package -or- use
> Metacello to do it (you have to know the relevant package names and
> prepare them with steps 3 and 4) -but- I have not checked if Metacello
> goes through the MCWorkingCopy, so this might not work yet. In that
> case, wrap "env beCurrentDuring: [...]" around the Metacello load.
> This might be the easier way after all...
> 6. in the workspace created in step 2, send #browse to a class loaded
> in step 5, to open a browser in the new environment
> 7. if appropriate and desired, import some or all of the new classes
> back into Smalltalk globals. This also simplifies opening browsers,
> because you can do it via the search box.
>    Smalltalk globals from: env import: { ... }.
> Then I do whatever I intend to do with that package. Probably port the
> code when selectors have changed as well, not only the class names.

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

> This is (ideally) no different from developing without environments.
> I did not commit the TestRunner yet... like for Workspace, I added an
> environment instvar there. Will do that later today.
>>> A remaining issue is that FSPath was renamed Path, which conflicts with
>>> ST80's Path class.

Given the broad meaning for the word "path", that was a very
ill-advised rename.  FilesystemPath is a much more correct and
appropriate for Smalltalk.

Equally, our own "Path" is so ambiguous, it's just wrong.  Sitting up
there as an abstract superclass -- we should rename it.

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

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

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


More information about the Squeak-dev mailing list