Re: Design Question: Pro Cons of KVC/KVO
Am Do,21.08.2008 um 08:58 schrieb Oleg Krupnov:
I need to make the design decision regarding how the model and the
views will be kept in sync with each other. Namely:
- I can use key-value coding and observing (KVC and KVO)
- I can use bindings (not sure if it's really different from the KVC/
KVO)
At least it isn't, since a binding registers KVO and uses KVC for data
retrievel.
- I can write the glue code myself
The concept of KVC/KVO is new to me. I have been looking at the Sketch
sample (a kind of application I am building myself too), which is
based on KVC/KVO, and I have found that the use of KVC/KVO makes the
program very unreadable and clumsy (like C++ COM code in Windows, you
know), because of the generic messages and hidden dependencies.
There is no magic. IMHO, it makes the code more readable, beause the
dependencies are not central, but encapsulated.
I suspect that it could be way easier, when a property's value
changes, to just explicitly send a concise and clearly named message
to the subscribed objects,
This is, what is done. The name of the message is
-observeValueForKeyPath:ofObject:change:context:
I think, you want to say, that if one changes a property, he sends a
message to a central MVC server, which distributes update messages.
Correct? Why?
if you want to have one method per synchronized property, use a
NSString instance as context and simply do that:
// Typed in mail.app, simple example
- observeValueForKeyPath:(NSString*)keyPath ofObject:
(id)observedObject change:(NSDictionary*)change context:(void*)context
{
NSString* updateMethode = [NSString stringWithFormat.@update%@,
context]; // I didn't care about upper case to keep it simple for
demonstration
SEL selector = NSSelectorFromString( updateMethod );
if( [self respondsToSelector:selector] ) {
[self performSelector:selector];
}
}
This will call a method with the name updateSize, if you set @size
as the context at registration.
But: Why?
Cheers,
Amin
than try to fit into the over-generalized
model of KVC/KVO for the sake of skipping a few lines of code. And I
still have to subscribe objects to objects with KVC/KVO, don't I?
Does anyone actually use KVC/KVO? What is your experience? Any
pros/cons, opinions and best practices would be appreciated.
Thanks
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de
This email sent to [EMAIL PROTECTED]
Amin Negm-Awad
[EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
I suspect that it could be way easier, when a property's value
changes, to just explicitly send a concise and clearly named message
to the subscribed objects,
This is, what is done. The name of the message is
-observeValueForKeyPath:ofObject:change:context:
Then how is it better than manual glue code?
I think, you want to say, that if one changes a property, he sends a message
to a central MVC server, which distributes update messages. Correct? Why?
No. Actually, the alternative approach that I kept in mind was that
each model object maintains an array of observers (like delegates or
just objects with a declared protocol) to all of which the
corresponding message is sent each time a property of the model object
changes.
For example,
idMyModelObjectObserver observer;
MyModelObject* myModelObject;
// subscribe observer
[myModelObject addObserver: observer];
// set some prop
[myModelObject setSomeProp:someValue];
@interface MyModelObject
{
NSMutableArray* m_observers;
id m_someProp;
}
@end
@implementation MyModelObject
- (void)addObserver:(idMyModelObjectObserver) observer
{
[m_observers addObject:observer];
}
- (void)setSomeProp:(id)newValue
{
// save new value
m_someProp = newValue;
// notify observers
idMyModelObjectObserver observer = nil;
for (observer in m_observers)
{
[observer somePropChanged];
}
}
@end
Is there something terribly wrong with this approach? The dependencies
are encapsulated. In addition, it seems that this approach gives me
more flexibility, say, if newValue is invalid, it can be rejected. Or,
for instance, when the entire MyModelObject gets removed from its
parent model object - in this case there is no property actually
modified, instead, a mutator message is received by the model, but the
observers still need to be notified. Can KVC/KVO monitor the contents
of an array of model objects? And so on. Even though KVC/KVO may
handle these cases too, my intuition tells me there can be cases when
the flexibility of KVC/KVO may run short compared to the manual code.
Anyway, even if I assume that KVC/KVO is at least not worse than
manual code, I don't see any real benefit so far. Except that it
allows me to get the scripting support for free (but I'd rather like
the scripting to be separate thing and not get in the way of the model
objects).
Could someone please try to explain me the rationale behind KVC/KVO
once again? :) Thanks
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
Am Do,21.08.2008 um 15:22 schrieb Oleg Krupnov:
I suspect that it could be way easier, when a property's value
changes, to just explicitly send a concise and clearly named message
to the subscribed objects,
This is, what is done. The name of the message is
-observeValueForKeyPath:ofObject:change:context:
Then how is it better than manual glue code?
1. You do not have to manage a list of observes. this is done by cocoa.
2. cocoas implementation is faster than everything you would program.
3. Less Coding for you
4. Compliance with cocoa concepts
Enough?
I think, you want to say, that if one changes a property, he sends
a message
to a central MVC server, which distributes update messages.
Correct? Why?
No. Actually, the alternative approach that I kept in mind was that
each model object maintains an array of observers (like delegates or
just objects with a declared protocol) to all of which the
corresponding message is sent each time a property of the model object
changes.
Sounds like KVO.
For example,
idMyModelObjectObserver observer;
MyModelObject* myModelObject;
// subscribe observer
[myModelObject addObserver: observer];
// set some prop
[myModelObject setSomeProp:someValue];
@interface MyModelObject
{
NSMutableArray* m_observers;
id m_someProp;
}
@end
@implementation MyModelObject
- (void)addObserver:(idMyModelObjectObserver) observer
{
[m_observers addObject:observer];
}
- (void)setSomeProp:(id)newValue
{
// save new value
m_someProp = newValue;
// notify observers
idMyModelObjectObserver observer = nil;
for (observer in m_observers)
{
[observer somePropChanged];
}
}
@end
Looks like a bad implementation oif KVO.
What is the advantage of reprogramming KVO?
Beside this: Do you want to use core data? What about core data
properties?
Is there something terribly wrong with this approach?
There is nothing wrong in programming a new string class. But why
don't you use NSString?
The dependencies
are encapsulated. In addition, it seems that this approach gives me
more flexibility, say, if newValue is invalid, it can be rejected.
Key value valdidation
Or,
for instance, when the entire MyModelObject gets removed from its
parent model object - in this case there is no property actually
modified, instead, a mutator message is received by the model, but the
observers still need to be notified. Can KVC/KVO monitor the contents
of an array of model objects?
Of course. Look at the array controller.
And so on. Even though KVC/KVO may
handle these cases too, my intuition tells me there can be cases when
the flexibility of KVC/KVO may run short compared to the manual code.
My intuition is, that you don't want to get deeper with KVO und KVC
and are searching for reasons to reject it.
Anyway, even if I assume that KVC/KVO is at least not worse than
manual code, I don't see any real benefit so far. Except that it
allows me to get the scripting support for free (but I'd rather like
the scripting to be separate thing and not get in the way of the model
objects).
Could someone please try to explain me the rationale behind KVC/KVO
once again? :) Thanks
In five minutes?
You want to hold an oberserver list for every property and every
object. This is done by KVO. And ist is done for KVC with Core Data.
And it works with bindings. And it is implemented very good through
isa-swizzling. And And And …
There is nothing wrong in writing a Cocoa II.
But: Why?
Cheers,
Amin Negm-Awad
[EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
Thanks Amin for responding. You are correct that there's no need to reinvent the wheel, and that's exactly what I'd like to avoid, that's why I am now re-reading about KVC/KVO and reconsidering it. So, does everybody really always use KVC/KVO for implementing MVC, in all projects? Is this the recommended best practice? BTW does anyone use Core Data? I've watched the video tutorial and it looks like too much magic. I would never guess how to make Core Data work for a drawing application like the Sketch. Is Core Data rather for database+forms apps? Thanks. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
Am Do,21.08.2008 um 16:41 schrieb Oleg Krupnov: Thanks Amin for responding. You are correct that there's no need to reinvent the wheel, and that's exactly what I'd like to avoid, that's why I am now re-reading about KVC/KVO and reconsidering it. So, does everybody really always use KVC/KVO for implementing MVC, in all projects? There are some situation, where glue code is neccessary. Imagine a outline view that has a items lib and some groups, where you can place items from the lib and see them in the outline view by opening the isclosure. Or you have items from different entities there. But even in this case it helps to use KVO on the parts to get synchronized. Is this the recommended best practice? BTW does anyone use Core Data? You're joking? I've watched the video tutorial and it looks like too much magic. I would never guess how to make Core Data work for a drawing application like the Sketch. Is Core Data rather for database+forms apps? 1. Core data is not a database. 2. I think, that you are new to cocoa and a little bit afraid of the magic things. Hey, dive into it, read documentation, try a little bit coding and so on. There is no magic. It's just new land for you. Thanks. Cheers, Amin Negm-Awad [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
Oleg, by all means, go ahead with what you started and spend more time learning about KVC/KVO. Yes, this is used in many many projects and I personally would really miss it if it wouldn’t be there. Actually, as you described yourself, if it wouldn’t be there, you’d had to brew something similar yourself. Which I did, coincidental, like 15 years ago under Mac OS 7 or so. Only that Apple can spend a lot more resources than you (I guess) or me (I’m sure) in making this right. And they did. Yes, it has a learning curve. And yes, it is sometimes unfortunate that the inner workings are a black box and can not be looked at with the debugger. Nevertheless, these are minor disadvantages in comparison to the whole thing. Amin already mentioned all the advantages of KVC/KVO as provided by Apple, including the integration with other Cocoa technologies, which a home-brewn solution could never provide. Concerning Core Data: it is equally great - inside its specs. Just take the build-in multi-level undo and redo support. Another great reason to use KVC/KVO, by the way: when Core Data undoes something, KVO is the way to get notified about these changes. Done consistently, this works simply beautiful. And I wouldn’t restrict Core Data to database+forms apps. You can certainly use it for a drawing application. Whether it is the best solution for this kind of application depends - as always - on many details. Hope this helps a little Kai On 21.8.2008, at 16:41, Oleg Krupnov wrote: Thanks Amin for responding. You are correct that there's no need to reinvent the wheel, and that's exactly what I'd like to avoid, that's why I am now re-reading about KVC/KVO and reconsidering it. So, does everybody really always use KVC/KVO for implementing MVC, in all projects? Is this the recommended best practice? BTW does anyone use Core Data? I've watched the video tutorial and it looks like too much magic. I would never guess how to make Core Data work for a drawing application like the Sketch. Is Core Data rather for database+forms apps? Thanks. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/kai%40granus.net This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
Am Do,21.08.2008 um 17:03 schrieb Oleg Krupnov: Amin, It is true that I am new to Cocoa, and although I find the documentation really great and engaging, I have sort of difficulty figuring out what technology is newer/more powerful/built on top of/ other technology. In particular, would you explain me, in just two words, what are the relations between and intended/typical applications of (in the context of implementing the MVC pattern) 1) KVC/KVO KVC is a very old (10.0?) technique to set properties of an entity. In comparison with setters you can choose (change) the property at run- time without changing your code: Entity* instance = …; // imagine this is set [instance setProperty:value]; // you know that You cannot change the name of the property without recompiling. This can be done with KVC: NSString* key; Entity* instance = …; // imagine this is set key= @property; [instance setValue:value forKey:key]; key= @another; [instance setValue:value forKey:key]; Since key is a NSString constructed at run-time, you can change the property at run-time. KVO is newer, I think 10.3 IIRC and something totally different: The core: You get a mesage, if you registered for a property of an instance, that changes. It's quite close to your code. There are differences between automatic and manual KVO, but this is the essence. 2) Bindings Bindings use KVO to get synchronized and KVC for reading/writing data. You can imagine a binding a command to an object, to observe the given key of the given instance. So, hmmm, usually an object starts a KVO, when it becomes bound. Conceptionally: - bind:(NSString*)boundPropertyKey toObject:(id)observed forKeyPath: (NSString*)observedProperty // start KVO [observed addObserver:self forKeyPath:observedProperty]; There are more features through binding options I omitted to clarify. KVO, KVC, and Bindings are placed between the MVC-layers. They typically synchronize a controller to the model and a view to the controller. (Inside a layer you typically do not need KVO, KVC, because the objects inside the same layer know each other. But of course you can use KVO, KVC) 3) Core Data Core data is not neccessarily related to KV*. It is simply a technology for your model to ease the boring work of defining entites, writing accessors, supporting serialization…. But core data is KVC- and KVO-compliant, that means, that you can set/ read properties to/from an core data entity and you're able to observe the properties. Short: You *can* use KV technologies with core data. Using core data or not and using KV* or not is orthogonal. 4) Anything else I may have overlooked? If Core Data is really that cool, why don't one always use it instead of KVC/KVO or maybe Bindings? See above. You do not use core data or KV*, but core data and KV* BTW I didn't say I thought Core Data was a database, I said it may be intended rather for database apps. Okay :-) The usage is quite simple (if I'm allowed to simplify that) Without core data In your model you have classes for entities, let's say Person, Department, Company, Account … These classes are typically subclsses of NSObject. So you have to define the ivars, write accessors (okay, Objctive-C 2 …), maybe support undoing, support serialization with NSCoding … With core data In many cases you do not need any subclass, but simply use NSManagedObject. The definition of the model can be done in the modeller very easy. Undoing, Coding and so on will work. Cheers Amin Negm-Awad [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
I have some quibbles... On Aug 21, 2008, at 12:54 PM, Erik Buck wrote: So, in summary, the whole point of KVC is to standardize the way an object’s properties are accessed regardless of how they are stored. Well, the real point, to my mind, is to increase the dynamism of property access. It's to allow properties to be accessed using data to select the property rather than code. Data that is determined at runtime or design time (IB). KVC also provides support (hooks) for change management so that any change to a property can have application defined side effects like registering an undo event or validating the change. Hooks other than the accessors it might invoke? I'm not aware of that. KVO Key Value Observing takes advantage of the change management hooks provided by Key Value Coding in order to notify other interested objects whenever an observed property changes. Again, I don't think KVO takes advantage of existing hooks. It adds those hooks by generating subclasses dynamically and isa-swizzling. Unless and until you add a KVO observer to an object, it doesn't have any hooks. KVO is also the basis of “Bindings”. I would go so far as to say “Bindings” are just a way to specify which objects observe which properties in which other objects using Interface Builder instead of writing code to register all those notification observers. Bindings do more than merely set up KVO observations. The classes which support bindings also determine what to do when changes are observed. Although KVO is “built upon KVC”, KVO really only needs change notifications. So, if you provide the change notifications, KVO will work even if you don’t really use KVC. I don't think that's true. KVO relies on KVC. How else can a KVO change notification include the old or new value? KVO will perform a KVC query for will/didChange... messages (including the implicit, automatic invocations of will/didChange... performed in the hooks it installs). Cheers, KEn___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
Remember that NeXT and Apple didn't just invent KVC, KVO, and Bindings out of thin air for no better reason than they were enamored of the idea. There was a substantial history of NeXTStep/OpenStep/Cocoa programs written. The developers at NeXT and then Apple recognized that there was a large body of repeated design elements and implementations for some very common tasks. Gradually they extracted these commonalities, generalized them, and implemented them in a way intended to allow the elimination of all (or most) of those previous custom implementations. In other words, there's a reason that the design you came up with on your own is so similar to what KVO actually does. It's because Apple has seen such designs before many, many times -- I'm sure they wrote their own implementations many times for many programs and frameworks -- and they eventually created KVO just so you (and they, and all of us) would never have to implement that same thing over again. The same with Bindings. Reading the Bindings guide actually describes the thought process behind this feature of the framework. Many, many projects were filled with repetitive controller glue code for updating views from models and vice versa. Apple figured out a way to write a feature into the frameworks to eliminate a huge amount of that repetitive glue code. So, while there's no rule that you have to use KVC, KVO, or Bindings in your own code, chances are good that you'll just end up reinventing them badly. If it weren't highly probable that you'd do that, then KVC, KVO, and Bindings wouldn't exist. Cheers, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
On Aug 21, 2008, at 7:12 PM, Ken Thomases wrote: I have some quibbles... On Aug 21, 2008, at 12:54 PM, Erik Buck wrote: So, in summary, the whole point of KVC is to standardize the way an object’s properties are accessed regardless of how they are stored. Well, the real point, to my mind, is to increase the dynamism of property access. It's to allow properties to be accessed using data to select the property rather than code. Data that is determined at runtime or design time (IB). I agree. Cocoa Design Patterns includes an entire chapter about the Associative Storage design pattern, and the whole point of the pattern is to provide dynamism that allows determination at runtime. I perhaps over simplified out of a desire to avoid pasting the whole Associative Storge pattern into the essay. KVC also provides support (hooks) for change management so that any change to a property can have application defined side effects like registering an undo event or validating the change. Hooks other than the accessors it might invoke? I'm not aware of that. In order to make your classes KVC compliant, you must either write the appropriate accessors or override the valueForKey: and related methods. The hooks in fact are the accessor methods or the valueForKey: type methods. KVO Key Value Observing takes advantage of the change management hooks provided by Key Value Coding in order to notify other interested objects whenever an observed property changes. Again, I don't think KVO takes advantage of existing hooks. It adds those hooks by generating subclasses dynamically and isa-swizzling. Unless and until you add a KVO observer to an object, it doesn't have any hooks. The hooks are just the accessor methods or KVC compliance methods. They exist for every KVC compliant class. However, you can use KVO with a class that is not totally KVC compliant if you call the appropriate willChangeValueForKey: and didChangeValueForKey: methods. Obviously it works best with KVC compliant classes. OK - I'll concede that KVO should only be used with KVC compliant classes. The last time I described all this in email, I was shot down for even bringing up the isa-swizzling becaust that's an obscure implementation detail... KVO is also the basis of “Bindings”. I would go so far as to say “Bindings” are just a way to specify which objects observe which properties in which other objects using Interface Builder instead of writing code to register all those notification observers. Bindings do more than merely set up KVO observations. The classes which support bindings also determine what to do when changes are observed. That's a detail. The essay was intentionally kept to the main points. I wanted to focus on the notification aspect because that's whate the original poster was trying to re-implement. Although KVO is “built upon KVC”, KVO really only needs change notifications. So, if you provide the change notifications, KVO will work even if you don’t really use KVC. I don't think that's true. KVO relies on KVC. How else can a KVO change notification include the old or new value? KVO will perform a KVC query for will/didChange... messages (including the implicit, automatic invocations of will/didChange... performed in the hooks it installs). OK OK - I'll concede that KVO should only be used with KVC compliant classes. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
On Aug 21, 2008, at 7:09 PM, Erik Buck wrote: On Aug 21, 2008, at 7:12 PM, Ken Thomases wrote: On Aug 21, 2008, at 12:54 PM, Erik Buck wrote: KVC also provides support (hooks) for change management so that any change to a property can have application defined side effects like registering an undo event or validating the change. Hooks other than the accessors it might invoke? I'm not aware of that. In order to make your classes KVC compliant, you must either write the appropriate accessors or override the valueForKey: and related methods. The hooks in fact are the accessor methods or the valueForKey: type methods. Well, OK. In that sense, every method is a hook, insofar as a subclass could override it to do something before/after/instead of what the method would normally do. When I think of hooks, I usually think of methods that exist solely to provide clients an opportunity to do something at certain points. The framework calls them not for its own purposes but just to give clients an opportunity to do something else. For example, the real meat of -[NSWindowController window] is in its -loadWindow method. However, for the convenience of its clients (and solely for that reason), it also invokes -windowWillLoad and -windowDidLoad (and the associated document's -windowControllerWillLoadNib: and - windowControllerDidLoadNib:, if present). And, of course, delegate methods are a prime example of hooks. I suppose that's a pedantic distinction, though. Again, I don't think KVO takes advantage of existing hooks. It adds those hooks by generating subclasses dynamically and isa- swizzling. Unless and until you add a KVO observer to an object, it doesn't have any hooks. The hooks are just the accessor methods or KVC compliance methods. They exist for every KVC compliant class. Technically, a class may be KVC-compliant even without the KVC accessors. If the class has the appropriately-named instance variable, it qualifies (although I'm sure we agree that programmers _should_ provide the accessors, especially for proper memory management). I guess, in that case, you might consider the -valueForKey: and - setValue:forKey: methods themselves to be the hooks. *shrug* Cheers, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
On 22 Aug 2008, at 1:03 am, Oleg Krupnov wrote: 4) Anything else I may have overlooked? I've read through this thread and it's very interesting. But one thing that has been overlooked - common or garden notifications. If all you want is to pick up a change in an object a notification is a simple way to do it without writing your own messaging system. It's less powerful than KVO but simpler to understand and much less fussy about managing its connections than KVO. Think of it as a half-way house between doing it all yourself and using KVO, which might seem to be too much magic for some. Check out NSNotificationCenter. cheers, Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
So, does everybody really always use KVC/KVO for implementing MVC, in all projects? Is this the recommended best practice? From code written after 10.2, yeah, pretty much. Coupled with the tools support in Interface Builder and the AppKit support with Cocoa Bindings, it's really not worth the effort of reimplementing KVC or KVO in general. BTW does anyone use Core Data? I've watched the video tutorial and it looks like too much magic. I would never guess how to make Core Data work for a drawing application like the Sketch Core Data is an ORM framework for Cocoa whose purpose is to fill the M part of MVC patterns. AppKit and Cocoa Bindings fill V and C respectively. Although it does not support client server databases, there are similar products in that enterprise space such as EOF, Hibernate, Cayenne, JDO, .NET Entity Framework, and the ActiveRecord pieces of Ruby on Rails. Just as all those products provide many more features than ODBC/JDBC (e.g. a database), so too does Core Data provide a lot more than raw data persistence. While I like to imagine that there is a pinch of magic in Core Data for specific technical problems, the concepts and features are not magical. The theory behind these systems dates back to the mid 70s, and they became commercially popularized in the 90s. You can ask wikipedia for more details about ORM and ERM. Core Data does not force you to use it with KVC or KVO, but since it leverages many of the same ideas, understanding KVC KVO first would be wise. Is Core Data rather for database+forms apps? No, Core Data is for Model objects within Cocoa applications. You can use it just as easily with a Foundation command line tool if you don't need Views or Controllers. - Ben ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
On Thu, Aug 21, 2008 at 10:27 PM, Graham Cox [EMAIL PROTECTED] wrote:
But one thing that has been overlooked - common or garden notifications. If
all you want is to pick up a change in an object a notification is a simple
way to do it without writing your own messaging system. It's less powerful
than KVO but simpler to understand and much less fussy about managing its
connections than KVO. Think of it as a half-way house between doing it all
yourself and using KVO, which might seem to be too much magic for some.
I don't think using notifications for communication between specific
objects is the best idea. I tend to think of notifications for
broadcasting state changes that any other object may be interested in.
For example, say I have a window with a toolbar and an NSSplitView.
It wouldn't make sense to use the delegation pattern between my split
view and my toolbar. So that leaves me with two options,
architecturally:
1) Create a C#-style event handler list. In C# (and other .NET
languages, but C#'s syntax is easiest), objects declare that they have
events. So a SplitView class in C# might have an event called Resize:
delegate void ResizeDelegate(object sender, EventArgs e)
class SplitView
{
public event ResizeDelegate Resize;
}
Then, somewhere I would wire my toolbar up to that event:
class Toolbar
{
public Toolbar()
{
// Make the SplitView notify us if it resizes
theSplitView.Resize += new ResizeDelegate(this.toolbar_Resized);
}
private toolbar_Resized(object sender, EventArgs e)
{
// Typical example: change the text on a show/hide side pane button
}
}
This approach is very in keeping with C#'s static typing; the events
an object can raise are well-defined members of the class. The
downside, though, is that somehow your client objects need to know
about all the objects that they want to attach themselves to. Your
object graph gets very, very dense if you have more than a few of
these sorts of events.
2) Broadcast notifications to anyone who may be interested.
@implementation SplitView
{
-(void) setSize:(NSSize)newSize
{
[[[NSNotificationCenter] defaultCenter]
postNotificationName:SplitViewResized object:self];
}
}
@end
Now my client objects can specifically listen for this message coming
from this SplitView, or they can listen for all messages, or just this
message from any SplitView.
@implementation ToolBar
{
-(id) init
{
[[[NSNotificationCenter] defaultCenter] addObserver:self
selector:@selector(splitViewResized:) object:mySplitView];
}
}
Much more flexible, but at the cost of knowing what messages the split
view might throw, and it loses the static typechecking that the C#
delegate approach affords; the C# event is typed as only taking
methods which return void and accept an object and an EventArgs, while
the Cocoa method will fail at runtime if ToolBar doesn't implement
-splitViewResized:.
The real power of notifications comes when you have, say, a hundred of
something. You want some UI element to know when any of your hundred
things enters state X (a collision, for example). With .NET events,
you have to register this object with each of your target objects. In
Cocoa, your objects just scream out and the client hears them.
--Kyle Sluder
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
On Fri, Aug 22, 2008 at 3:59 PM, Kyle Sluder
[EMAIL PROTECTED] wrote:
@implementation ToolBar
{
-(id) init
{
[[[NSNotificationCenter] defaultCenter] addObserver:self
selector:@selector(splitViewResized:) object:mySplitView];
}
-(void)dealloc
{
[[NSNotificationCenter] defaultCenter] removeObserver:self];
[super dealloc];
}
@end
I've generally only used notifications for events that can't be
handled with KVO---ie. those that aren't associated with a property
change; and I've noticed that this is generally the trend in Cocoa
frameworks as well. Why use NSNotifications when there's already
perfectly good notification mechanism?
That said, notifications also give you a lot more flexibility about
when observers will be called, and coalescence of multiple
notifications.
Phil
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Design Question: Pro Cons of KVC/KVO
On 22 Aug 2008, at 2:22 pm, Phil wrote: Why use NSNotifications when there's already perfectly good notification mechanism? Indeed, but notifications have been around a lot longer than KVO, so there are still plenty of places in Cocoa that notifications are used for legacy reasons. Also, as others have mentioned, they are better when you have more than one object that you might have an interested in. With KVO you have to subscribe to each individually, with notifications you can subscribe to the same notification from any object that might send it. Horses for courses, as usual. My point was that notifications are a messaging mechanism; KVO or rolling your own aren't the only games in town. So notifications should be considered when thinking about messaging. If subsequently rejected for a given design, so be it. cheers, Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
