gnustep-dev
[Top][All Lists]
Advanced

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

Re: Recent key-value encoding changes to NSObject.


From: Nicola Pero
Subject: Re: Recent key-value encoding changes to NSObject.
Date: Mon, 11 Feb 2002 14:38:12 +0000 (GMT)

>  >| The recent changes to key-value encoding in NSObject introduce five non 
>  >| standard new methods
>  >| to the API which are not used by anything (apart from some EOF code I 
>  >| guess) and make the
>  >| key-value coding methods less efficient.
>  >| 
>  >| It seems to me that the derived objects for which these changes are 
>  >| intended (which exist in a
>  >| separate framework), should actually be overriding the key-value 
>  >| encoding methods of NSObject,
>  >| rather than the NSObject methods being hacked to call methods in the 
>  >| derived objects.
>  >| 
>  >| I therefore intend to revert the changes since it seems to me that the 
>  >| required effect would
>  >| be more efficiently (and certainly more cleanly) be implemented 
>  >| elsewhere.
> 
> I don't really agree because 
>         - it make redundant code (with possible problem due to later non 
> synchronization of these two codes)
>         - AFAIK, KVC is not used in core or GUI part.
>         - today it's only used in EOF but it could be used elsewhere to add 
> support for ivar like storing mechanisms
> (use of dictionaries, for example) or specific optimizations (hasing the ivar 
> names for example).
>         - EOF specifications don't say you have to derive your objects from 
> EOGenericRecord and it
> could be nice to have a minimum coding to make objects storing things in 
> dictionaries or something else without
> having to rewrite the whole KVC functions
>         - I think Apple has the same kind of 'hack' 
>         - the loss of efficiency (this adds only 2 methods call) is IMHO not 
> very high compared to the whole KVC process
> (GSInstanceVariableInfo have a while loop to iterate on ivars and do a strcmp 
> on each ivar name). IMHO, a better way to improve the
> previous and existing KVC part may be to make only one call to 
> GSInstanceVariableInfo instead of the actual 2 calls.

I think you are not answering to Richard's point.  Richard is not against
having KVC methods in core/base, or against improving the existing ones.  
He is against that particular way of modifying them.

And I agree with Richard.

NSObject -handleQueryWithUnboundKey: raises an exception.  It is meant to
be overridden in subclasses.  If in a subclass you want to do something
else (than raising an exception), you override -handleQueryWithUnboundKey:
to do whatever you want, then if what you want to do fails, you call
[super handleQueryWithUnboundKey:].

I don't see why having an additional NSObject -_handleQueryWithUnboundKey:
method would make things simpler.  You would then override
_handleQueryWithUnboundKey: instead of handleQueryWithUnboundKey:.  Where
is the advantage ?

I don't know exactly what you're trying to do, so I/we might be missing
something, in which case let us know exactly what the problem is.

To me, it looks like the existing public API should provide enough options
to allow you do whatever key value coding you need.  I'm certainly against
hacking the API and adding private hacks for unclear reasons.  If the
public API is not enough powerful to implement the key value coding you
need - which I strongly doubt - then we need to extend the public API (and
as little as possible), /not/ add a private one.




reply via email to

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