[Top][All Lists]
[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.
- Re[6]: Recent key-value encoding changes to NSObject., (continued)
- Re[6]: Recent key-value encoding changes to NSObject., Manuel Guesdon, 2002/02/11
- Re: Re[6]: Recent key-value encoding changes to NSObject., Nicola Pero, 2002/02/11
- Re[8]: Recent key-value encoding changes to NSObject., Manuel Guesdon, 2002/02/11
- Re[9]: Recent key-value encoding changes to NSObject., Manuel Guesdon, 2002/02/14
- Re: Recent key-value encoding changes to NSObject., Richard, 2002/02/14
- Re[2]: Recent key-value encoding changes to NSObject., Manuel Guesdon, 2002/02/15
- Re[2]: Recent key-value encoding changes to NSObject., Manuel Guesdon, 2002/02/22
- Re: Re[4]: Recent key-value encoding changes to NSObject., Richard Frith-Macdonald, 2002/02/11
- Re[6]: Recent key-value encoding changes to NSObject., Manuel Guesdon, 2002/02/11
- Re: Re[6]: Recent key-value encoding changes to NSObject., Richard Frith-Macdonald, 2002/02/11
Re: Recent key-value encoding changes to NSObject.,
Richard Frith-Macdonald <=
Re: Re[2]: Recent key-value encoding changes to NSObject., Nicola Pero, 2002/02/11
Re[4]: Recent key-value encoding changes to NSObject., Manuel Guesdon, 2002/02/11
Re: Re[4]: Recent key-value encoding changes to NSObject., Nicola Pero, 2002/02/11
Re[6]: Recent key-value encoding changes to NSObject., Manuel Guesdon, 2002/02/11
Re: Re[6]: Recent key-value encoding changes to NSObject., Nicola Pero, 2002/02/11
Re[8]: Recent key-value encoding changes to NSObject., Manuel Guesdon, 2002/02/11
Re: Re[6]: Recent key-value encoding changes to NSObject., Richard Frith-Macdonald, 2002/02/11