• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???


  • Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • From: Mark Munz <email@hidden>
  • Date: Mon, 3 Jan 2005 09:58:08 -0600


On Jan 3, 2005, at 3:16 AM, Izidor Jerebic wrote:
I tried really hard to incorporate bindings in my new application. Really.
But somehow I couldn't do it. I could not point my finger to the reason, but it just didn't feel right.


Now that I read Scott Stevenson's remark, that "most developers still insist on using datasource methods" or something like that, I did some thinking and came with these reasons why I could not use bindings. First two are practical, the last and most important is a principled one:

1. Non-debuggable
Once you use bindings, and program does not behave as it should, you can only slaughter chicken or goats and dance and pray to the all-mighty god of Cocoa to help you. There is no tool to help you see what is and is not happening. This is a major drawback

I agree 100%. Users expect magic (things just work the way the expected it to), but programmers need to be able to step through each piece to insure the results are expected (and that the unexpected is dealt with). I get the whole KVC, KVO concept. That's not what bugs me with bindings. It's the magic, in particular with NSArrayController that I've struggled with.


In my opinion, the fact that basic operations like Drag-n-Drop still require "glue code" defeats the purpose of a general purpose array controller. If I have NSObjects that support the copy-protocol, Drag-n-Drop should be free. I think it adds to the confusion -- well, the data is automatically handled for you via magic in the NSArrayController unless you're doing a drag-n-drop, then you have to perform the magic (great, but what happens when you don't understand what the magic is because it not well documented).

I don't think NSArrayController is a bad idea (far from it), but the implementation and vague documentation (I've seen every sample I could get my hands on -- including Malcolm's, Apple's docs, updated books, etc) make it much harder to learn/use. There is no way to tell what is happening with the NSArrayController objects. I can get stuff to work, but I don't understand why the stuff I got to work does what it does. It's very click-and-pray. I've would love to see an example of NSArrayController with just one basic type -- NSStrings. Essentially, an example of a basic List. Start off without drag-n-drop support. Then add it. Do I need to encapsulate my NSStrings in another object or can I use them directly (I don't believe I've seen an example of them used directly)?

There is also a general flaw with using Interface Builder to develop applications -- there are no diagnostic tools that easily show connections (Outlets and Actions and Bindings) for each object. You essentially have to click on each object and view the connections, bindings individually.

I will download this debug tool mentioned by someone else in hopes that it will help. I believe there definitely needs to be support built-into Cocoa to make debugging with the use of bindings easier. In my opinion, click-and-pray is not the way to develop code.

Finally FWIW, if the intent is to reduce code, I think there should be a way to support basic properties without having to write the glue code to access each one property.

And yes, I will write up some this via bugs in RADAR to Apple, but that often times results in it just being called a duplicate because the needs/wants are fairly obvious.

Mark Munz

_______________________________________________
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


  • Follow-Ups:
    • Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
      • From: mmalcolm crawford <email@hidden>
References: 
 >Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>)

  • Prev by Date: Re: EPS to NSBezierPath
  • Next by Date: Re: 2 problems.
  • Previous by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Next by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Index(es):
    • Date
    • Thread