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.
Als
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
{
[[NSNotificationCe
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 pow
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 t
Ken,
Thanks for your explanation of the development of KVC, KVO, and
Bindings.
As a geezer who spent most of his career coding in assembler on IBM
mainframes beginning in the late 60's, it is still sometimes difficult
not having total control over my code.
KVC, KVO, and Bindings is one of th
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
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
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,
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
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.
I love answering questions that require an essay. So here is my essay.
I think my forthcoming Cocoa Design Patterns book does a good job of
explaining the patterns used to implement Cocoa and reused to implement Cocoa
applications. In particular, the book explains how techniques like Key
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 e
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 s
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
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 fo
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 rec
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:cha
>> 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 tha
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/
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)
- I can write the "glue code" myself
The concep
20 matches
Mail list logo
