[Pharo-project] On the toaster again
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
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 -- denker@acm.org http://www.marcusdenker.de
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 -- denker@acm.org http://www.marcusdenker.de
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <stephane.ducasse@inria.fr>:
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  --  denker@acm.org http://www.marcusdenker.de
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Hilaire Fernandes -
Marcus Denker -
Stéphane Ducasse