Environment declarations vs bindings

> On 30 September 2016 at 14:36, Chris Muller <[hidden email]> 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
>

> On Oct 3, 2016, at 02:49, Stéphane Rollandin <[hidden email]> wrote:
>
>
>> There must of course be a decent manual (or collection of writings that constitute a manual) because *nobody* would do something stupid like adding a bunch of code that doesn’t have an obvious reason for being or an explanation of how to use it, or examples. It just couldn’t happen.
>
> Ok, I know this is Squeak's tradition.
>
> The fact is I'm genuinely interested in Environments, as I used to be interested in Traits but never did anything with it because of the missing support.
>
> What a waste.
>
>
> Stef
>
>

> On 02-10-2016, at 10:49 PM, Stéphane Rollandin <[hidden email]> wrote:
>
>
>> There must of course be a decent manual (or collection of writings that constitute a manual) because *nobody* would do something stupid like adding a bunch of code that doesn’t have an obvious reason for being or an explanation of how to use it, or examples. It just couldn’t happen.
>
> Ok, I know this is Squeak's tradition.
>
> The fact is I'm genuinely interested in Environments, as I used to be interested in Traits but never did anything with it because of the missing support.
>
> What a waste.

>
> Hi--
>
>      We don't need a system dictionary at all. We can make each class
> responsible for its own name literal, use subclass/metaclass references
> for reachability, and make all other globals the responsibility of some
> class. Every class can have any name; the execution machinery doesn't
> care. Other metadata about classes (e.g., author) can be used to
> disambiguate their names when compiling sources. We can store all that
> metadata in a module system, to manage the history of all versions of
> all classes and methods in the system.
>
>      The Naiad module system that I wrote[1] implements this. I've
> adapted it to the latest Squeak and plan to release it this month.
>
>
> -C
>
> [1] http://thiscontext.com/naiad
>
> --
> Craig Latta
> Black Page Digital
> Amsterdam | San Francisco
> [hidden email]
> +31 6 2757 7177 (SMS ok)
> + 1 415 287 3547 (no SMS)
>
>