[Pharo-project] class message
Hello! What has changed in implementation "class" message in between Pharo 1.3 and 1.4? Is it compiled inline now or something like that? -- Milan Mimica http://sparklet.sf.net
On Sat, May 26, 2012 at 8:31 PM, Milan Mimica <milan.mimica@gmail.com>wrote:
Hello!
What has changed in implementation "class" message in between Pharo 1.3 and 1.4? Is it compiled inline now or something like that?
no, the other way around, now #class is NOT bytecoded, and therefore is managed as a normal message send.
-- Milan Mimica http://sparklet.sf.net
-- Mariano http://marianopeck.wordpress.com
On 26 May 2012 20:32, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Sat, May 26, 2012 at 8:31 PM, Milan Mimica <milan.mimica@gmail.com>wrote:
Hello!
What has changed in implementation "class" message in between Pharo 1.3 and 1.4? Is it compiled inline now or something like that?
no, the other way around, now #class is NOT bytecoded, and therefore is managed as a normal message send.
That is much better. Thanks! I like progress even if it breaks old code. -- Milan Mimica http://sparklet.sf.net
What has changed in implementation "class" message in between Pharo 1.3 and 1.4? Is it compiled inline now or something like that?
no, the other way around, now #class is NOT bytecoded, and therefore is managed as a normal message send.
That is much better. Thanks! I like progress even if it breaks old code.
:) But we always try to minimize else we would go much faster and btw class should not break older code :)
-- Milan Mimica http://sparklet.sf.net
On 26 May 2012 20:53, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
What has changed in implementation "class" message in between Pharo 1.3
and 1.4? Is it compiled inline now or something like that?
no, the other way around, now #class is NOT bytecoded, and therefore is
managed as a normal message send.
That is much better. Thanks! I like progress even if it breaks old code.
:) But we always try to minimize else we would go much faster and btw class should not break older code :)
It did break Mocketry (http://www.squeaksource.com/Mocketry) I would also suspect it breaks things like WriteBarrier and Magma and similar stuff performing magic. -- Milan Mimica http://sparklet.sf.net
On 26 May 2012 20:59, Milan Mimica <milan.mimica@gmail.com> wrote:
On 26 May 2012 20:53, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
What has changed in implementation "class" message in between Pharo 1.3 and 1.4? Is it compiled inline now or something like that?
no, the other way around, now #class is NOT bytecoded, and therefore is managed as a normal message send.
That is much better. Thanks! I like progress even if it breaks old code.
:) But we always try to minimize else we would go much faster and btw class should not break older code :)
It did break Mocketry (http://www.squeaksource.com/Mocketry) I would also suspect it breaks things like WriteBarrier and Magma and similar stuff performing magic.
but how you can make an omelet without breaking eggs? :)
-- Milan Mimica http://sparklet.sf.net
-- Best regards, Igor Stasenko.
On May 26, 2012, at 8:59 PM, Milan Mimica wrote:
On 26 May 2012 20:53, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
What has changed in implementation "class" message in between Pharo 1.3 and 1.4? Is it compiled inline now or something like that?
no, the other way around, now #class is NOT bytecoded, and therefore is managed as a normal message send.
That is much better. Thanks! I like progress even if it breaks old code.
:) But we always try to minimize else we would go much faster and btw class should not break older code :)
It did break Mocketry (http://www.squeaksource.com/Mocketry) I would also suspect it breaks things like WriteBarrier and Magma and similar stuff performing magic.
normally it should do the opposite: as #class is not special, magic is much easier. Marcus -- Marcus Denker -- http://marcusdenker.de
On 26 May 2012 22:10, Marcus Denker <marcus.denker@inria.fr> wrote:
On May 26, 2012, at 8:59 PM, Milan Mimica wrote:
On 26 May 2012 20:53, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
What has changed in implementation "class" message in between Pharo 1.3 and 1.4? Is it compiled inline now or something like that?
no, the other way around, now #class is NOT bytecoded, and therefore is managed as a normal message send.
That is much better. Thanks! I like progress even if it breaks old code.
:) But we always try to minimize else we would go much faster and btw class should not break older code :)
It did break Mocketry (http://www.squeaksource.com/Mocketry) I would also suspect it breaks things like WriteBarrier and Magma and similar stuff performing magic.
normally it should do the opposite: as #class is not special, magic is much easier.
you have no trust, you're from academia :)
    Marcus
-- Best regards, Igor Stasenko.
:) But we always try to minimize else we would go much faster and btw class should not break older code :)
It did break Mocketry (http://www.squeaksource.com/Mocketry) I would also suspect it breaks things like WriteBarrier and Magma and similar stuff performing magic.
How mockery used the fact that class was not a send message? Stef
Hello 2012/5/26 Milan Mimica <milan.mimica@gmail.com>
On 26 May 2012 20:53, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
What has changed in implementation "class" message in between Pharo 1.3
and 1.4? Is it compiled inline now or something like that?
no, the other way around, now #class is NOT bytecoded, and therefore is
managed as a normal message send.
That is much better. Thanks! I like progress even if it breaks old code.
:) But we always try to minimize else we would go much faster and btw class should not break older code :)
It did break Mocketry (http://www.squeaksource.com/Mocketry)
Thank's for report. Try to fix it today. Now I dont know how #class message can broke something. When I found answer I try to explain
Best regards, Denis
no, the other way around, now #class is NOT bytecoded, and therefore is managed as a normal message send.
That is much better. Thanks! I like progress even if it breaks old code.
:) But we always try to minimize else we would go much faster and btw class should not break older code :)
It did break Mocketry (http://www.squeaksource.com/Mocketry)
Thank's for report. Try to fix it today. Now I dont know how #class message can broke something. When I found answer I try to explain
Thanks denis. I'm curious too. Stef
I found problem. Proxy classes in SMock and Mocketry are subclasses of ProtoObject which not implements #class. But proxy classes use "self class" in some methods (like #printOn: implementation). I add #class implementation from Object to ProtoObject and all SMock and Mocketry tests become green. So questions: Is ProtoObject should implement #class? Can we move #class method from Object to ProtoObject? 2012/5/27 Stéphane Ducasse <stephane.ducasse@inria.fr>
no, the other way around, now #class is NOT bytecoded, and therefore is managed as a normal message send.
That is much better. Thanks! I like progress even if it breaks old code.
:) But we always try to minimize else we would go much faster and btw class should not break older code :)
It did break Mocketry (http://www.squeaksource.com/Mocketry)
Thank's for report. Try to fix it today. Now I dont know how #class message can broke something. When I found answer I try to explain
Thanks denis. I'm curious too.
Stef
On Sun, May 27, 2012 at 11:02 AM, Denis Kudriashov <dionisiydk@gmail.com>wrote:
I found problem.
Proxy classes in SMock and Mocketry are subclasses of ProtoObject which not implements #class. But proxy classes use "self class" in some methods (like #printOn: implementation).
I add #class implementation from Object to ProtoObject and all SMock and Mocketry tests become green.
So questions: Is ProtoObject should implement #class? Can we move #class method from Object to ProtoObject?
ups....good catch! indeed, we should move it to ProtoObject.
2012/5/27 Stéphane Ducasse <stephane.ducasse@inria.fr>
no, the other way around, now #class is NOT bytecoded, and therefore is managed as a normal message send.
That is much better. Thanks! I like progress even if it breaks old code.
:) But we always try to minimize else we would go much faster and btw class should not break older code :)
It did break Mocketry (http://www.squeaksource.com/Mocketry)
Thank's for report. Try to fix it today. Now I dont know how #class message can broke something. When I found answer I try to explain
Thanks denis. I'm curious too.
Stef
-- Mariano http://marianopeck.wordpress.com
On 27 May 2012 11:40, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Sun, May 27, 2012 at 11:02 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
I found problem.
Proxy classes in SMock and Mocketry are subclasses of ProtoObject which not implements #class. But proxy classes use "self class" in some methods (like #printOn: implementation).
I add #class implementation from Object to ProtoObject and all SMock and Mocketry tests become green.
So questions: Is ProtoObject should implement #class? Can we move #class method from Object to ProtoObject?
ups....good catch! indeed, we should move it to ProtoObject.
mm.. why? the more we put to ProtoObject, the more it looks like Object. at some point you will see not difference between them, and then someone will come with a brilliant idea of having one more "clean" class ahead - ProtoProtoObject. -- Best regards, Igor Stasenko.
On Sun, May 27, 2012 at 2:31 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 27 May 2012 11:40, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Sun, May 27, 2012 at 11:02 AM, Denis Kudriashov <dionisiydk@gmail.com
wrote:
I found problem.
Proxy classes in SMock and Mocketry are subclasses of ProtoObject which not implements #class. But proxy classes use "self class" in some methods (like #printOn: implementation).
I add #class implementation from Object to ProtoObject and all SMock and Mocketry tests become green.
So questions: Is ProtoObject should implement #class? Can we move #class method from Object to ProtoObject?
ups....good catch! indeed, we should move it to ProtoObject.
mm.. why?
Because ALL objects do have a class. Right? if you want to change the semantics of #class then just subclass and change it. This is not the real reason, but in addition because since previously #class used to have a special bytecode, it means it was understood by "everybody". So at least with this we don't break anything. For me it does not make sense to get a #dnu for #class when the object really has a class.
the more we put to ProtoObject, the more it looks like Object. at some point you will see not difference between them, and then someone will come with a brilliant idea of having one more "clean" class ahead - ProtoProtoObject.
You cannot tell that to me ;) I was the one who spent 2 days to remove all the 10 menthods tryNamedPrimitive* from ProtoObject.
-- Best regards, Igor Stasenko.
-- Mariano http://marianopeck.wordpress.com
On Sun, May 27, 2012 at 3:06 PM, Douglas Brebner < squeaklists@fang.demon.co.uk> wrote:
On 27/05/2012 13:46, Mariano Martinez Peck wrote:
Because ALL objects do have a class. Right?
Wasn't one of the reasons for ProtoObject to enable building non-class (e.g. prototype) object systems?
I don't know. I though it was for proxies because Object included already too much messages. -- Mariano http://marianopeck.wordpress.com
On 27 May 2012 14:46, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Sun, May 27, 2012 at 2:31 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 27 May 2012 11:40, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Sun, May 27, 2012 at 11:02 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
I found problem.
Proxy classes in SMock and Mocketry are subclasses of ProtoObject which not implements #class. But proxy classes use "self class" in some methods (like #printOn: implementation).
I add #class implementation from Object to ProtoObject and all SMock and Mocketry tests become green.
So questions: Is ProtoObject should implement #class? Can we move #class method from Object to ProtoObject?
ups....good catch! indeed, we should move it to ProtoObject.
mm.. why?
Because ALL objects do have a class. Right? if you want to change the semantics of #class then just subclass and change it.
mmm.. no. IMO, in pure sense, all objects having behavior. but behavior is not a class (and we can even have two classes to discriminate between them). yes, it is _almost_ a class.. but much more obscure.. i doesn't needs to be compatible with Class protocol.. You should know pretty well, what requirements VM side puts for a valid behavior: - superclass, methoddict, format. which enables VM to do method lookup and creating an instances. now, if you make ProtoObject to answer message #class, one will assume that the object it answers should conform to a full-fledged Class protocol. But of course it should not. Maybe i nitpicking about terminology.. but i think at that level we should make it clear: - all objects having behavior! - some object's behaviors are Classes - some object's behaviors are Metaclasses - but there could be any other.
This is not the real reason, but in addition because since previously #class used to have a special bytecode, it means it was understood by "everybody". So at least with this we don't break anything. For me it does not make sense to get a #dnu for #class when the object really has a class.
the more we put to ProtoObject, the more it looks like Object. at some point you will see not difference between them, and then someone will come with a brilliant idea of having one more "clean" class ahead - ProtoProtoObject.
You cannot tell that to me ;)Â I was the one who spent 2 days to remove all the 10 menthods tryNamedPrimitive* from ProtoObject.
yes :)
-- Best regards, Igor Stasenko.
-- Mariano http://marianopeck.wordpress.com
-- Best regards, Igor Stasenko.
So questions: Is ProtoObject should implement #class? Can we move #class method from Object to ProtoObject?
ups....good catch! indeed, we should move it to ProtoObject.
mm.. why?
Because ALL objects do have a class. Right? if you want to change the semantics of #class then just subclass and change it.
mmm.. no. IMO, in pure sense, all objects having behavior. but behavior is not a class (and we can even have two classes to discriminate between them). yes, it is _almost_ a class.. but much more obscure.. i doesn't needs to be compatible with Class protocol.. You should know pretty well, what requirements VM side puts for a valid behavior: - superclass, methoddict, format. which enables VM to do method lookup and creating an instances.
now, if you make ProtoObject to answer message #class, one will assume that the object it answers should conform to a full-fledged Class protocol. But of course it should not.
Maybe i nitpicking about terminology.. but i think at that level we should make it clear: - all objects having behavior! - some object's behaviors are Classes - some object's behaviors are Metaclasses - but there could be any other.
I agree with all that. But as you said, I think you are going too low level in details. For example, I would call class to all your previous list. All objects have a class, which can be Class, Metaclass, whatever. In addition, if we don't add #class in ProtoObject, then there are some of broken messages like #cannotInterpret: and #pointsTo since they send #class to self. -- Mariano http://marianopeck.wordpress.com
On 27 May 2012 21:04, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
So questions: Is ProtoObject should implement #class? Can we move #class method from Object to ProtoObject?
ups....good catch! indeed, we should move it to ProtoObject.
mm.. why?
Because ALL objects do have a class. Right? if you want to change the semantics of #class then just subclass and change it.
mmm.. no. IMO, in pure sense, all objects having behavior. but behavior is not a class (and we can even have two classes to discriminate between them). yes, it is _almost_ a class.. but much more obscure.. i doesn't needs to be compatible with Class protocol.. You should know pretty well, what requirements VM side puts for a valid behavior: - superclass, methoddict, format. which enables VM to do method lookup and creating an instances.
now, if you make ProtoObject to answer message #class, one will assume that the object it answers should conform to a full-fledged Class protocol. But of course it should not.
Maybe i nitpicking about terminology.. but i think at that level we should make it clear: - all objects having behavior! - some object's behaviors are Classes - some object's behaviors are Metaclasses - but there could be any other.
I agree with all that. But as you said, I think you are going too low level in details. For example, I would call class to all your previous list. All objects have a class, which can be Class, Metaclass, whatever. In addition, if we don't add #class in ProtoObject, then there are some of broken messages like #cannotInterpret: and #pointsTo since they send #class to self.
okay i agree. i just don't like that in case of ProtoObject the name of a message is a bit misleading, while perfectly ok for Object. Maybe we should state that in method comment, that only instances of Object and its subclasses are guarantee that answer of #class message are Class.. for ProtoObject (or its direct descendant) is can be anything.
-- Mariano http://marianopeck.wordpress.com
-- Best regards, Igor Stasenko.
Mariano Martinez Peck wrote:
So questions: Is ProtoObject should implement #class? Can we move #class method from Object to ProtoObject?
ups....good catch! indeed, we should move it to ProtoObject.
mm.. why?
Because ALL objects do have a class. Right? if you want to change the semantics of #class then just subclass and change it.
mmm.. no. IMO, in pure sense, all objects having behavior. but behavior is not a class (and we can even have two classes to discriminate between them). yes, it is _almost_ a class.. but much more obscure.. i doesn't needs to be compatible with Class protocol.. You should know pretty well, what requirements VM side puts for a valid behavior: - superclass, methoddict, format. which enables VM to do method lookup and creating an instances.
now, if you make ProtoObject to answer message #class, one will assume that the object it answers should conform to a full-fledged Class protocol. But of course it should not.
Maybe i nitpicking about terminology.. but i think at that level we should make it clear: - all objects having behavior!
A passing naive thought... Does ProtoObject then need #behavior? ...which can be overridden to return Class, Metaclass or Other as appropriate? ...such that Mocketry, #cannotInterpret and #pointsTo etc can use this instead of #class?
- some object's behaviors are Classes - some object's behaviors are Metaclasses - but there could be any other.
I agree with all that. But as you said, I think you are going too low level in details. For example, I would call class to all your previous list. All objects have a class, which can be Class, Metaclass, whatever. In addition, if we don't add #class in ProtoObject, then there are some of broken messages like #cannotInterpret: and #pointsTo since they send #class to self.
On 28 May 2012 15:30, Ben Coman <btc@openinworld.com> wrote:
Mariano Martinez Peck wrote:
So questions: Is ProtoObject should implement #class? Can we move #class method from Object to ProtoObject?
ups....good catch! indeed, we should move it to ProtoObject.
mm.. why?
Because ALL objects do have a class. Right? if you want to change the semantics of #class then just subclass and change it.
mmm.. no. IMO, in pure sense, all objects having behavior. but behavior is not a class (and we can even have two classes to discriminate between them). yes, it is _almost_ a class.. but much more obscure.. i doesn't needs to be compatible with Class protocol.. You should know pretty well, what requirements VM side puts for a valid behavior: - superclass, methoddict, format. which enables VM to do method lookup and creating an instances.
now, if you make ProtoObject to answer message #class, one will assume that the object it answers should conform to a full-fledged Class protocol. But of course it should not.
Maybe i nitpicking about terminology.. but i think at that level we should make it clear: - all objects having behavior!
A passing naive thought... Does ProtoObject then need #behavior? Â ...which can be overridden to return Class, Metaclass or Other as appropriate? ...such that Mocketry, #cannotInterpret and #pointsTo etc can use this instead of #class?
i dont have a strong opinion. from one side it is good to have a separate method for that, just to indicate that protoobject don't needs to have a fully formed class. from another side, its implementation will be same as in #class, and #behavior selector may be used already by various projects for different purposes.
- some object's behaviors are Classes - some object's behaviors are Metaclasses - but there could be any other.
I agree with all that. But as you said, I think you are going too low level in details. For example, I would call class to all your previous list. All objects have a class, which can be Class, Metaclass, whatever. In addition, if we don't add #class in ProtoObject, then there are some of broken messages like #cannotInterpret: and #pointsTo since they send #class to self.
-- Best regards, Igor Stasenko.
Ok. Now I just fix SMock by adding #class method. And I publish new ConfigurationOfMocketry to squeaksource/MetacelloRepository. All tests green
On 27 May 2012 11:02, Denis Kudriashov <dionisiydk@gmail.com> wrote:
I add #class implementation from Object to ProtoObject and all SMock and Mocketry tests become green.
Yes, that fixes any problems I can think of with it. Otherwise #class ends up in #doesNotUnderstand which is special for proxy objects... -- Milan Mimica http://sparklet.sf.net
On Sat, May 26, 2012 at 8:36 PM, Milan Mimica <milan.mimica@gmail.com>wrote:
On 26 May 2012 20:32, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Sat, May 26, 2012 at 8:31 PM, Milan Mimica <milan.mimica@gmail.com>wrote:
Hello!
What has changed in implementation "class" message in between Pharo 1.3 and 1.4? Is it compiled inline now or something like that?
no, the other way around, now #class is NOT bytecoded, and therefore is managed as a normal message send.
That is much better. Thanks! I like progress even if it breaks old code.
breaks? can you give us an example? beause it has to be something quite hacky or low level, has't it?
-- Milan Mimica http://sparklet.sf.net
-- Mariano http://marianopeck.wordpress.com
participants (8)
-
Ben Coman -
Denis Kudriashov -
Douglas Brebner -
Igor Stasenko -
Marcus Denker -
Mariano Martinez Peck -
Milan Mimica -
Stéphane Ducasse