gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[4]: Recent key-value encoding changes to NSObject.


From: Manuel Guesdon
Subject: Re[4]: Recent key-value encoding changes to NSObject.
Date: Mon, 11 Feb 2002 17:01:15 +0100 (CET)

On Mon, 11 Feb 2002 15:37:55 +0000 (GMT) Nicola Pero <address@hidden> wrote:
 >| > _handleQueryWithUnboundKey: is only a part of the changes. I agree these 
 >2 methods aren't really necessary (I've
 >| just
 >| > added them to allow derived objects to handle these case hiddenly).
 >| 
 >| Ok - so we agree it's better to remove them

OK.



 >| Storing key/values in dictionaries might be implemented as follows -
 >| 
 >| if you always want to store stuff in a dictionary, override
 >| takeValue:forKey: to save the key/value in a dictionary, and valueForKey:
 >| to read the value from the dictionary.
 >| 
 >| if you want to store stuff in a dictionary only if an ivar with that name
 >| is not found, override handleTakeValue:forUnboundKey: to set the key/value
 >| in the dictionary, and handleValueForUnboundKey: to return the value of
 >| the key from the dictionary.
 >| 
 >| Other cases are managed similarly.
 >| 
 >| I'm not sure why you need to tell outside that something has some 'ivars'.  
 >| To get a list of the valid keys for an object, I suppose that would be
 >| done by asking for its NSClassDescription.  So - you would go by
 >| subclassing NSClassDescription, and returning the appropriate attributes
 >| (you subclass NSClassDescription to return different attributes, adding to
 >| [super attributes]).  I'm not sure what the state of that is in gnustep.

I'll try to summarize the problems I've found and the reason why I've added 
this in core/base.
Take this hierarchy Class X derived from EOGenericRecord derived from NSObject
Say X will have 2 values: a and b.
o X will store A in an ivar (_a) the other is stored in EOGenericRecord in a 
dictionary "_values".
        _value is a special dictionary which know it's keys (including a even 
if it won't store it itself in
our case. There's a reason for this that I could explain if you want :-).

X will have the following methods:
        -(id)a
        {
                [self storedValueForKey:@"a"];
        }
        -(void)setA:(id)anA
        {
                [self takeStoredValue:anA
                        ForKey:@"a"];
        }
        -(id)b
        {
                [self storedValueForKey:@"a"];
        }
        -(void)setB:(id)aB
        {
                [self takeStoredValue:aB
                        ForKey:@"b"];
        }
        

 [x valueForKey:@"a"] should return the ivar _a (not the dictioanry value for a)
 [x valueForKey:@"b"] should return the  dictioanry value.

Another point: these methods may not be defined (we may want to defined them 
just to call -a instead of calling valueFor:@"a"
but just for commodities). X objects are defined by user and he can do near 
whatever he want if he respect MacOS X/EOF/WO specs.

Without the last patch and without copying NSObject valueForKey, 
storedValueForKey:, takeValue:forKey: takeStoredValue:forKey:, I can't see how 
to
do this (you'll get infinite loop: remember, last try of storedValueForKey: 
will call -a)

Manuel
PS: Sorry for this long thread :-)


--
______________________________________________________________________
Manuel Guesdon - OXYMIUM <address@hidden>
14 rue Jean-Baptiste Clement  -  93200 Saint-Denis  -  France
Tel: +33 1 4940 0999  -  Fax: +33 1 4940 0998




reply via email to

[Prev in Thread] Current Thread [Next in Thread]