On the toaster again

>
> On 26.02.2009, at 10:37, Hilaire Fernandes wrote:
>
>> It looks like Association>>isSpecialWriteBinding is gone in Pharo.  
>> Can
>> someone confirm it?
>>
>> It hurt because it is used by Magma..
>>
>
> Yes. cleanup of un-used code.
>
> The story was that: In the SystemDictionary ("Smalltalk") there are  
> the
> classes. Technically, Dictionaries are collections of Associations.
>
> Now, "Smalltalk" has globals *and* classes. Which means, we can do
>
> Object := nil.
>
> And everthing is dead.
>
> This is especially a problem in an ende-user scripting systems (e.g.
> something
> more powerful than etoys, but targeted at non-programmers).
>
> Sometime in the last century, someone started to work on making Squeak
> more stable (or
> secure for some meaning of secure).
>
> Now, one can fix the assignment problem in two places:
>
> A) name analysis of the compiler. The place where all the other
> warning are generated.
> B) replacing the association in the Smalltalk dictionary by one that
> can not be changed.
>    (here "value:" raises an exception).
>
> The isSpecialWriteBinding was the test to check if the binging was
> read=only or read/write.
> Some classes where referenced using a read-only binging (those that
> where very old), but
> all new classes where referenced using a normal association.
>
> There was no code in the image that would create
> ReadOnlyVariableBindings. It was never used
> in this century. And: is that really at the right level, that change?
> For controlling assignments,
> the compiler's checking phase is much better.
>
> If one wants to make the structure of the sytem (the "structural
> model" in the sense of structural
> reflection) read-only, this does not help at all. Remember, this hack
> just touches *one* place in the
> object graph that starts with "Smalltalk". It does not, for example,
> secure the method-dictonary. Nor
> changes to the inhertance hierarchy.
>
> This is actually a very cool topic of research... and we are
> incidentally actually working just now
> on a paper that shows one cool direction of providing "read only"
> views on shared object graphs like
> the one that represents the structure of the system.
>
> Marcus
>
>
> --
> Marcus Denker  --  [hidden email]
> http://www.marcusdenker.de
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> marcus
>
> to help hilaire what woul dbe the fall back
> and deprecated version so that magma works?
>
> Stef
> On Feb 26, 2009, at 10:54 AM, Marcus Denker wrote:
>
>>
>> On 26.02.2009, at 10:37, Hilaire Fernandes wrote:
>>
>>> It looks like Association>>isSpecialWriteBinding is gone in Pharo.
>>> Can
>>> someone confirm it?
>>>
>>> It hurt because it is used by Magma..
>>>
>>
>> Yes. cleanup of un-used code.
>>
>> The story was that: In the SystemDictionary ("Smalltalk") there are
>> the
>> classes. Technically, Dictionaries are collections of Associations.
>>
>> Now, "Smalltalk" has globals *and* classes. Which means, we can do
>>
>> Object := nil.
>>
>> And everthing is dead.
>>
>> This is especially a problem in an ende-user scripting systems (e.g.
>> something
>> more powerful than etoys, but targeted at non-programmers).
>>
>> Sometime in the last century, someone started to work on making Squeak
>> more stable (or
>> secure for some meaning of secure).
>>
>> Now, one can fix the assignment problem in two places:
>>
>> A) name analysis of the compiler. The place where all the other
>> warning are generated.
>> B) replacing the association in the Smalltalk dictionary by one that
>> can not be changed.
>>    (here "value:" raises an exception).
>>
>> The isSpecialWriteBinding was the test to check if the binging was
>> read=only or read/write.
>> Some classes where referenced using a read-only binging (those that
>> where very old), but
>> all new classes where referenced using a normal association.
>>
>> There was no code in the image that would create
>> ReadOnlyVariableBindings. It was never used
>> in this century. And: is that really at the right level, that change?
>> For controlling assignments,
>> the compiler's checking phase is much better.
>>
>> If one wants to make the structure of the sytem (the "structural
>> model" in the sense of structural
>> reflection) read-only, this does not help at all. Remember, this hack
>> just touches *one* place in the
>> object graph that starts with "Smalltalk". It does not, for example,
>> secure the method-dictonary. Nor
>> changes to the inhertance hierarchy.
>>
>> This is actually a very cool topic of research... and we are
>> incidentally actually working just now
>> on a paper that shows one cool direction of providing "read only"
>> views on shared object graphs like
>> the one that represents the structure of the system.
>>
>>       Marcus
>>
>>
>> --
>> Marcus Denker  --  [hidden email]
>> http://www.marcusdenker.de
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>