On Nov 12, 2010, at 12:05, Remco Poelstra wrote:
> If I understand it correctly, for all properties, each and everytime,
> valueForUndefinedKey is called?
Correct.
> So I do also need to override setValue:forUndefinedKey in case 2? To make
> sure that the properties end up in the dictionary?
Op 12 nov 2010, om 20:44 heeft Quincey Morris het volgende geschreven:
In case 2, which seems like the superior solution, the private
dictionary isn't being accessed via KVC at all, so the only KVC
behavior you're concerned with is that of the wrapper.
Ah, that explains. If I understand i
On Nov 12, 2010, at 11:13, Remco Poelstra wrote:
> Otherwise the valueForKey is called on my wrapper, instead of the dictionary
> that contains the real keys. I don't see how else the KVC logic should find
> out about that instance variable.
The dictionary is a private implementation detail of
Op 12 nov 2010, om 19:16 heeft Quincey Morris het volgende geschreven:
As as been said several times in this thread, you *shouldn't*
override 'valueForKey:', but instead override
'valueForUndefinedKey:' like this:
Is this kind of override ok?:
valueForKey: {
[properties valueForKey:
On Nov 12, 2010, at 10:16, Quincey Morris wrote:
> - (id) valueForUndefinedKey: (NSString*) key {
> id retVal=[properties objectForKey:key]; // note: NOT 'valueForKey:'
> if (!retVal) {
> //fetch value from network
> //We do not wait for the value
> }
On Nov 12, 2010, at 01:45, Remco Poelstra wrote:
> @interface PropertiesController: NSObject {
> NSMutableDictionary *properties;
> }
>
> -valueForKey:
> -setValue:forKey:
> @end
> @implementation PropertiesController
> valueForKey {
> id retVal=[properties valueForKey:key];
>
Op 12 nov 2010, om 13:37 heeft Graham Cox het volgende geschreven:
>
> On 12/11/2010, at 11:24 PM, Remco Poelstra wrote:
>
>> But if I do not override setValue:forKey: How does the KVC logic now that it
>> should not try to call setValue:forKey: on my wrapper object, but on the
>> enclosed di
On 12/11/2010, at 11:24 PM, Remco Poelstra wrote:
> But if I do not override setValue:forKey: How does the KVC logic now that it
> should not try to call setValue:forKey: on my wrapper object, but on the
> enclosed dictionary instead? Do I not need to override setValue:forKey: and
> call [myDi
Op 12-11-2010 12:13, Graham Cox schreef:
nil from NSDictionary means no value associated with the key
(dictionaries cannot store 'nil' as a value) so this is your cue to
go fetch. The problem is that the object on which
-valueForUndefinedKey: is invoked is the dictionary, not your
wrapper, and si
On 12/11/2010, at 8:45 PM, Remco Poelstra wrote:
> If I ommit the valueForKey method, how does the KVC logic now, that it should
> check the properties variable?
> Further more, NSDictionary seems to always return a value, so all keys are
> "defined", they just return nil sometimes. How can val
Op 12-11-2010 2:26, Ken Thomases schreef:
On Nov 11, 2010, at 4:57 PM, Graham Cox wrote:
On 12/11/2010, at 3:30 AM, Ken Thomases wrote:
You should not override -setValue:forKey: or -valueForKey: if you can avoid it. Instead,
implement the methods -setValue:forUndefinedKey: and -valueForUnde
On Nov 11, 2010, at 4:57 PM, Graham Cox wrote:
> On 12/11/2010, at 3:30 AM, Ken Thomases wrote:
>
>> You should not override -setValue:forKey: or -valueForKey: if you can avoid
>> it. Instead, implement the methods -setValue:forUndefinedKey: and
>> -valueForUndefinedKey:. They are precisely f
On Nov 11, 2010, at 2:57 PM, Graham Cox wrote:
>
> On 12/11/2010, at 3:30 AM, Ken Thomases wrote:
>
>> You should not override -setValue:forKey: or -valueForKey: if you can avoid
>> it. Instead, implement the methods -setValue:forUndefinedKey: and
>> -valueForUndefinedKey:. They are precise
On Thu, Nov 11, 2010 at 2:57 PM, Graham Cox wrote:
> Understood, but the OP's problem as I understand it is that it's not that the
> key is undefined, but the value associated with it is uninitialized. So
> rather than return nil, or zero, he wants to trigger a remote fetch of the
> value. KVC
On 12/11/2010, at 3:30 AM, Ken Thomases wrote:
> You should not override -setValue:forKey: or -valueForKey: if you can avoid
> it. Instead, implement the methods -setValue:forUndefinedKey: and
> -valueForUndefinedKey:. They are precisely for implementing "dynamic"
> properties in this manner
On Nov 11, 2010, at 7:11 AM, Graham Cox wrote:
> Just write a wrapper for -setObject:forKey: and -valueForKey: The first just
> calls the same method on its (mutable) dictionary, the second can first check
> for whether the value is actually present and if not kick off some task to
> fetch it,
Op 11-11-2010 14:11, Graham Cox schreef:
On 12/11/2010, at 12:01 AM, Remco Poelstra wrote:
Seems so :) I just tried that and observing the change of properties is now
non-functional, as the request for observing is not forwarded to the
NSDictionary behind my own object. Seems I've to overrid
On 12/11/2010, at 12:01 AM, Remco Poelstra wrote:
> Seems so :) I just tried that and observing the change of properties is now
> non-functional, as the request for observing is not forwarded to the
> NSDictionary behind my own object. Seems I've to override a whole lot of
> methods to forward
Op 11-11-2010 13:48, Graham Cox schreef:
On 11/11/2010, at 11:41 PM, Remco Poelstra wrote:
Leaves me wondering whether I should hardcode all properties (82 items) on my
own object or try to make a more intelligent subclass of NSMutableDictionary.
Or maybe a composite object?
If the requir
On 11 Nov 2010, at 12:41, Remco Poelstra wrote:
> Op 10-11-2010 15:31, Quincey Morris schreef:
>> On Nov 10, 2010, at 06:10, jonat...@mugginsoft.com wrote:
>>
>>> I was just thinking that the overrides would provide a convenient point to
>>> process all requests for undefined properties.
>>> D
On 11/11/2010, at 11:41 PM, Remco Poelstra wrote:
> Leaves me wondering whether I should hardcode all properties (82 items) on my
> own object or try to make a more intelligent subclass of NSMutableDictionary.
> Or maybe a composite object?
If the requirement is simply to distinguish between
Op 10-11-2010 15:31, Quincey Morris schreef:
On Nov 10, 2010, at 06:10, jonat...@mugginsoft.com wrote:
I was just thinking that the overrides would provide a convenient point to
process all requests for undefined properties.
Depends on the design and requirements of the model I suppose.
I do
On Nov 10, 2010, at 06:10, jonat...@mugginsoft.com wrote:
> I was just thinking that the overrides would provide a convenient point to
> process all requests for undefined properties.
> Depends on the design and requirements of the model I suppose.
I don't think that's happening here -- the prop
On 10 Nov 2010, at 14:05, Quincey Morris wrote:
> On Nov 10, 2010, at 05:58, jonat...@mugginsoft.com wrote:
>
>> On 10 Nov 2010, at 12:47, Remco Poelstra wrote:
>>
>>> Hi,
>>>
>>> I've an object which properties I access via key-value coding. These
>>> properties are sometimes "uninitialized
On Nov 10, 2010, at 05:58, jonat...@mugginsoft.com wrote:
> On 10 Nov 2010, at 12:47, Remco Poelstra wrote:
>
>> Hi,
>>
>> I've an object which properties I access via key-value coding. These
>> properties are sometimes "uninitialized" (that means, the real value needs
>> to be read from the W
On 10 Nov 2010, at 12:47, Remco Poelstra wrote:
> Hi,
>
> I've an object which properties I access via key-value coding. These
> properties are sometimes "uninitialized" (that means, the real value needs to
> be read from the Wifi network). I would like to detect a read of such
> property and
Hi,
I've an object which properties I access via key-value coding. These properties
are sometimes "uninitialized" (that means, the real value needs to be read from
the Wifi network). I would like to detect a read of such property and then
fetch it from the network. It's not a problem that in th
27 matches
Mail list logo
