Hi, In the attached png I show how 'annotations' is a dictionary in the "all inst vars" entry, while it is nil in the 'annotations' entry. The reason is that #instVarNamed: is redefined in RGClassDescriptionDefinition to answer the RGInstanceVariableDefinition representing the requested instance variable of the *represented class* (or nil if there is no instance variable with that name). I know that a purpose of ring entities is to be polymorphic with the represented system entities. But #instVarNamed: is protocol of Object, not of Class or ClassDescription. I you agree I will open an issue and submit a fix: To rename the method in RGClassDescriptionDefinition to #instanceVariableNamed: and update the test. MartÃn
yep this sounds about right. ... otherwise we have to start override #class as well ;) On 2013-09-18, at 06:18, Martin Dias <tinchodias@gmail.com> wrote:
Hi,
In the attached png I show how 'annotations' is a dictionary in the "all inst vars" entry, while it is nil in the 'annotations' entry.
The reason is that #instVarNamed: is redefined in RGClassDescriptionDefinition to answer the RGInstanceVariableDefinition representing the requested instance variable of the *represented class* (or nil if there is no instance variable with that name).
I know that a purpose of ring entities is to be polymorphic with the represented system entities. But #instVarNamed: is protocol of Object, not of Class or ClassDescription.
I you agree I will open an issue and submit a fix:
To rename the method in RGClassDescriptionDefinition to #instanceVariableNamed: and update the test.
MartÃn <Screen Shot 2013-09-18 at 10.57.18 AM.png>
I'm trying to really understand because it depends if ring should be a layer that should be used in place of real object. And to me Ring should be this layer. We could imagine that all the tools manipulate ring objects. If you introduce a new message then this opens the door to isKindOf: hell (or you should add this message to object too and the inspector should only use instVarNamed: and cannot work with Ring). I do not know what is the solution but it is not to simply add a message. So what is the real problem? On Sep 18, 2013, at 11:18 AM, Martin Dias <tinchodias@gmail.com> wrote:
Hi,
In the attached png I show how 'annotations' is a dictionary in the "all inst vars" entry, while it is nil in the 'annotations' entry.
I do not get the problem
The reason is that #instVarNamed: is redefined in RGClassDescriptionDefinition to answer the RGInstanceVariableDefinition representing the requested instance variable of the *represented class* (or nil if there is no instance variable with that name).
I know that a purpose of ring entities is to be polymorphic with the represented system entities. But #instVarNamed: is protocol of Object, not of Class or ClassDescription.
I you agree I will open an issue and submit a fix:
To rename the method in RGClassDescriptionDefinition to #instanceVariableNamed: and update the test.
MartÃn <Screen Shot 2013-09-18 at 10.57.18 AM.png>
RGClassDescriptionDefinition should be polymorphic with ClassDescription. But #instVarNamed: is protocol of Object, so why to override it there? Concretely, I have instances of RGClassDefinition and I can't: 1) inspect them as regular objects 2) use STON to serialize Because both use #instVarNamed:, which is answering nil. MartÃn On Wed, Sep 18, 2013 at 5:07 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I'm trying to really understand because it depends if ring should be a layer that should be used in place of real object. And to me Ring should be this layer. We could imagine that all the tools manipulate ring objects. If you introduce a new message then this opens the door to isKindOf: hell (or you should add this message to object too and the inspector should only use instVarNamed: and cannot work with Ring). I do not know what is the solution but it is not to simply add a message.
So what is the real problem?
On Sep 18, 2013, at 11:18 AM, Martin Dias <tinchodias@gmail.com> wrote:
Hi,
In the attached png I show how 'annotations' is a dictionary in the "all inst vars" entry, while it is nil in the 'annotations' entry.
I do not get the problem
The reason is that #instVarNamed: is redefined in RGClassDescriptionDefinition to answer the RGInstanceVariableDefinition representing the requested instance variable of the *represented class* (or nil if there is no instance variable with that name).
I know that a purpose of ring entities is to be polymorphic with the represented system entities. But #instVarNamed: is protocol of Object, not of Class or ClassDescription.
I you agree I will open an issue and submit a fix:
To rename the method in RGClassDescriptionDefinition to #instanceVariableNamed: and update the test.
MartÃn <Screen Shot 2013-09-18 at 10.57.18 AM.png>
On Sep 18, 2013, at 5:28 PM, Martin Dias <tinchodias@gmail.com> wrote:
RGClassDescriptionDefinition should be polymorphic with ClassDescription. But #instVarNamed: is protocol of Object, so why to override it there?
Concretely, I have instances of RGClassDefinition and I can't:
1) inspect them as regular objects 2) use STON to serialize
Because both use #instVarNamed:, which is answering nil.
but why does it answer nil and not the object?
MartÃn
On Wed, Sep 18, 2013 at 5:07 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I'm trying to really understand because it depends if ring should be a layer that should be used in place of real object. And to me Ring should be this layer. We could imagine that all the tools manipulate ring objects. If you introduce a new message then this opens the door to isKindOf: hell (or you should add this message to object too and the inspector should only use instVarNamed: and cannot work with Ring). I do not know what is the solution but it is not to simply add a message.
So what is the real problem?
On Sep 18, 2013, at 11:18 AM, Martin Dias <tinchodias@gmail.com> wrote:
Hi,
In the attached png I show how 'annotations' is a dictionary in the "all inst vars" entry, while it is nil in the 'annotations' entry.
I do not get the problem
The reason is that #instVarNamed: is redefined in RGClassDescriptionDefinition to answer the RGInstanceVariableDefinition representing the requested instance variable of the *represented class* (or nil if there is no instance variable with that name).
I know that a purpose of ring entities is to be polymorphic with the represented system entities. But #instVarNamed: is protocol of Object, not of Class or ClassDescription.
I you agree I will open an issue and submit a fix:
To rename the method in RGClassDescriptionDefinition to #instanceVariableNamed: and update the test.
MartÃn <Screen Shot 2013-09-18 at 10.57.18 AM.png>
On Wed, Sep 18, 2013 at 7:47 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 18, 2013, at 5:28 PM, Martin Dias <tinchodias@gmail.com> wrote:
RGClassDescriptionDefinition should be polymorphic with ClassDescription. But #instVarNamed: is protocol of Object, so why to override it there?
Concretely, I have instances of RGClassDefinition and I can't:
1) inspect them as regular objects 2) use STON to serialize
Because both use #instVarNamed:, which is answering nil.
but why does it answer nil and not the object?
you can try by inspecting this, for example: Integer asRingDefinition if you click in the inspector on 'annotations', which is an instvar of RGClassDefinition, what you see is nil. This is because #instVarNamed: tries to find 'annotations' in Integer (not in the RGClassDefinition).
On Sep 18, 2013, at 5:29 PM, Martin Dias <tinchodias@gmail.com> wrote:
RGClassDescriptionDefinition should be polymorphic with ClassDescription. But #instVarNamed: is protocol of Object, so why to override it there?
Concretely, I have instances of RGClassDefinition and I can't:
1) inspect them as regular objects 2) use STON to serialize
Because both use #instVarNamed:, which is answering nil.
To me it looks wrong for RGClassDefinition implementing #instVarNamed:. Marcus
RGClassDescriptionDefinition should be polymorphic with ClassDescription. But #instVarNamed: is protocol of Object, so why to override it there?
Concretely, I have instances of RGClassDefinition and I can't:
1) inspect them as regular objects 2) use STON to serialize
Because both use #instVarNamed:, which is answering nil.
To me it looks wrong for RGClassDefinition implementing #instVarNamed:.
probably (this is the question of layering) now it also means that we should have a look at the class protocol to access instance variables so that we have an Object API but also a good Class/RingClass API. Stef
To me it looks wrong for RGClassDefinition implementing #instVarNamed:.
probably (this is the question of layering) now it also means that we should have a look at the class protocol to access instance variables so that we have an Object API but also a good Class/RingClass API.
Stef
I didn't understand what you said. I think this is false polymorphism here: Object >> instVarNamed: ---> answers the value of the inst var (or raises an error if it doesn't exist) RGClassDescriptionDefinition >> instVarNamed: ---> answers a RGInstanceVariableDefinition (or nil if it doesn't exist) MartÃn
participants (4)
-
Camillo Bruni -
Marcus Denker -
Martin Dias -
Stéphane Ducasse