On Thu, Mar 02, 2017 at 08:15:26PM -0600, Chris Muller wrote:
> >
> >>
> >>> 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.

Renaming FSPath to Path was just plain stupid. But with respect to Environments,
that may be exactly the use case we are interested in. Somebody did something
stupid, and we have no way of changing it. Now we are faced with the problem of
using some package of general interest that happens to depend on the stupid thing
that we cannot fix. What to do?

There are plenty of kludgy hacks that might be applied to work around a problem
like this. I have done quite a few of them in my OSProcess package in an ongoing
effort to keep pace with various random refactorings and ill-advised cleaning
initiatives. That experience leaves me wondering if there might not be a better
way of dealing with such issues.

I do not really know if Environments will provide a practical solution, or if
instead it will just end up adding complexity without really carrying its weight.
Time will tell. But my gut feel tells me that Environments is both simple and
general in design, and that makes it worth the effort to see if we can find a
way put it to good use.

So let's get these changes into trunk. They are invisible to those of us not
working directly with Environments, and they appear to be very important for
anyone who might want to make practical use of Environments.

Dave