[squeak-dev] Environment declarations vs bindings

H. Hirzel hannes.hirzel at gmail.com
Sat Oct 1 22:00:14 UTC 2016


you write

'Environments abstracts, and makes uniform, the binding of names to
variables (which includes classes and globals).

the implementing of Environments focuses attention on a often
neglected part of programming.'

This is what we are looking for. An explanation of the _concept_
behind environments. This concept is not obvious for most people here
on the list......

On 10/1/16, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 30 September 2016 at 14:36, Chris Muller <asqueaker at gmail.com> wrote:
>> >> I don't like the idea of CurrentEnvironment at all. IMO global state
>> >> stinks.
>> >> It would mean that a lotta behavior would change by simply switching
>> >> one
>> >> shared variable...
>> >> I see it more like a not so clever workaround to make tools still work
>> in
>> >> presence of environments with minimal changes.
>> >
>> >
>> > Global state does indeed stink, which is why Environments is so nice,
>> > because "global" isn't global anymore.
>> This deserves some qualification.  Its true that writable globals
>> stink, you never know what state its going to be in, and updating it
>> introduces contention, etc.  However, Class names don't suddenly point
>> to a different class object within the context of a running
>> application, and no one ever replaces Smalltalk with a new instance.
>> These globals are just "there" -- read-only bindings which don't
>> suffer the stinky issues associated with writable globals.
>> I'm glad Nicolas started the other thread asking "what's it for?"  To
>> me, that's the most important question -- is there something actually
>> truly useful gained in exchange for complicating the language and
>> tools?  Is it only about everyone being able to have elegant,
>> prefix-less class names all loaded into one image?  Most of the
>> use-cases mentioned in this and the other threads were just "cool ways
>> to handle a one-off problem."
>> For the real world, we have been wanting smaller, more modular images.
>> The conditions of having less code and responsibility in those smaller
>> images bodes them less likely to benefit from Environments.  Multiple
>> small images passing messages over the network lets those Smalltalk
>> applications run on multiple processor cores, compared to one
>> monolithic image with all the code loaded and disambiguated via a
>> hierarchy of Environment imports/exports and running on just one
>> process core.
>> In 15 years, I think I've had just one name collision between classes
>> of different packages (neither of which used prefixes).  I think I
>> simply renamed one of them.  Dynamic system.  With Environments, I
>> would still have had to write some code to do various
>> imports/exports/renames, etc.. and so it doesn't actually save me any
>> development effort.  I guess it boils down to letting me keep pretty,
>> but ambiguous, names in the code.  But, I actually prefer prefixes...
>> Not trying to be a party pooper, but complexity is commonplace,
>> simplicity is rare.  If we still have a simple system, we should value
>> that aspect and try to keep it that way.  At least _optionally_...
>> Best,
>>   Chris
> Well, there's simple, and there's simplistic, and these are not the same
> thing. Environments abstracts, and makes uniform, the binding of names to
> variables (which includes classes and globals). Instead of the single, and
> therefore specialised, and therefore apt to make klunky, mapping of names
> to things, the implementing of Environments focuses attention on a often
> neglected part of programming.
> But I've had these discussions before, and I don't have the energy to
> pursue them, therefore I don't really have a voice in the matter.
> I am, however, sick to death of things being invented in Smalltalk, only to
> die in its birthplace, while the rest of the world sees value, and
> wholeheartedly takes up the concept. I'm not saying you're doing this now,
> Chris, but I have often, often heard people in the Squeak community say
> "oh, it was Too Complicated, it Wasn't Simple, Not Worth It" while Ruby,
> Perl, Clojure, Fortress, Scala all say "yep, great idea, thanks!".
> frank

More information about the Squeak-dev mailing list