Re: Feature suggestions for easier debugging of Cocoa Bindings.
Re: Feature suggestions for easier debugging of Cocoa Bindings.
- Subject: Re: Feature suggestions for easier debugging of Cocoa Bindings.
- From: "Corey O'Connor" <email@hidden>
- Date: Tue, 19 Apr 2005 16:26:10 -0700
On 4/19/05, John Brownlow <email@hidden> wrote:
> Couple of points in response:
> intuitive. In general, bindings *do* generate useful debugging info
> once you are pointing them at an object. The tricky thing is figuring
> out how to point at the right object, and how to know when it has
> changed. This gets less tricky.
This is exactly the bit I would like tools to help debugging.
> The Cocoa bindings reference is your friend.
The reference reminds me of Straustrup. Full of useful bits and
insight, with no time wasted on making a set of cohesive documents to
explain bindings from every viewpoint. ;-) What I would like, however,
is not documented as a feature in the current implementation. :-)
> 2) It is easy to do your own logging by placing turnable-offable NSLog
> calls in the accessors. Accessorizer will let you do this. It helps. It
Ah. I have no trouble debugging accessors. I'm having trouble
debugging the process the key-value encoding system goes through
before even calling the accessor. Once I get to the accessor, NSLog is
as useful as always.
>
> 3) I think you are wrong about 'no selection' and 'null'. In obj-C it
> is perfectly valid to send invocations to nil objects and bindings
> should be no different. In trivial cases your model should always
> exist, but imagine what happens with a tree of objects, where a leaf
> might have no branches. The default behavior is helpful here.
Hmmm.. I still don't see how I am wrong. Depending on your data
model, not having a particular model property could indicate that the
state of the data is inconsistent with the expected data model. This
is an error that needs to be caught as soon as possible.
If my data model is "Person has a first name, and a last name".
While "first name" and "last name" can be zero length strings, both
those properties still have to exists according to my data model. If
those properties did not even exist (Null), then something is
seriously wrong! I would want to know as soon as possible in that
case.
If your data model was of the form "blah can have foo", then,
sure, being able to specify what happens when your model object does
not have the foo property is required.
Still, it is only my opinion that the ideal life cycle for any MVC
UI is that the model exists before the view or controller exists. I
wouldn't be surprised if *that* was wrong. :-)
> An assert might be a nice feature though.
That's my only point :-)
> 4) If you think bindings are inscrutable, wait for C******a. You will
> be the meat in an inscrutable sandwich.
On the other hand, the only reason I find bindings odd, is due to
the inconsistency between what data models the bindings can represent
and what data models can exist. Not enabling a null property to signal
an error can be inconsistent with the desired data model.
Thanks for the reply!
--
-Corey O'Connor
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden