On the toaster again

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

On the toaster again

Hilaire Fernandes-4
It looks like Association>>isSpecialWriteBinding is gone in Pharo. Can
someone confirm it?

It hurt because it is used by Magma..

--
http://blog.ofset.org/hilaire

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: On the toaster again

Marcus Denker

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
Reply | Threaded
Open this post in threaded view
|

Re: On the toaster again

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: On the toaster again

Hilaire Fernandes-4
I added myself the missing method as an extension in my package. This
will do it for now.

Hilaire

2009/2/26 Stéphane Ducasse <[hidden email]>:

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



--
http://blog.ofset.org/hilaire

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project