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: Richard Frith-Macdonald
Subject: Re: Recent key-value encoding changes to NSObject.
Date: Mon, 11 Feb 2002 14:42:13 +0000

On Monday, February 11, 2002, at 01:50 PM, Manuel Guesdon wrote:

On Mon, 11 Feb 2002 09:45:33 +0000 Richard Frith-Macdonald <address@hidden> wrote:

|
| 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)

Not sure I understand that ... how much code would be redundant? I'd have thought that a subclass could call the superclass code if it was not wanting to perform special actions ... so there should be little/no redundancy.

        - 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).

I wasn't talking about removing key-value coding support ... just about sticking to the (as far as I can see perfectly adequate) MacOS-X API rather than adding extra unnecessary methods.

- 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

But the whole point of the KVC stuff is that objects just need to implement set/get methods to do this stuff, or in the case where the possible keys aren't known at compile time (like fetching from a dictionary) overrides a few standard methods. I don't see how the additional methods can make things any simpler. In fact, I'd argue that by making the API larger they actually make things more complex.

So, for instance if object X is storing values in a dictionary, and someone calls [X valueForKey: @"Y"] The class of X only needs to override -respondsToSelector: methodSignatureForSelector: and forwardInvocation: so that when -valueForKey: tries to use -getY the value from the dictionary is returned.

For greater efficiency, one could override -methodForSelector: rather than forwardInvocation: of course,
eg.
1. -respondsToSelector: always says YES for any getXXX or setXXX: selectors.
2. -methodSignatureForSelector: always returns an OK signature for them.
3. -methodForSelector: actually returns a method which will fetch then from the dictionary.

        - I think Apple has the same kind of 'hack'

If true, that's not really a justification.

- 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.

My main concern is with ugliness/complexity - lowered efficiency is just extra ... why add to the API with code that is not only unneccessary, but decreases efficiency too? If it *increased* efficiency, I might see some justification for
adding the code, but it decreases it (however slightly).

If/when we do come to considering efficiency, there are a lot of options to try - certainly the string code handling the key names could be speeded up a lot, and caching per-class info may be possible (though I haven't figured out how to do that in a thread-safe way without the overhead of locking for every cache access, which would probably slow things down more than the caching would speed them up) ... but that's another issue.




reply via email to

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