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
<[email protected]> 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 <[email protected]> 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>
>
>

Reply via email to