3 ms·

> My big wish for the next major iOS SDK is to get bindings. I wouldn't expect this. Honestly I'd expect things to go the other way: 10.7 maybe deprecating bin

by jsolson 16y ago

> My big wish for the next major iOS SDK is to get bindings. I wouldn't expect this. Honestly I'd expect things to go the other way: 10.7 maybe deprecating bindings on the Desktop for things like table and outline views. Particularly since they added NSTableViewDataSource/Delegate and NSOutlineViewDataSource/Delgate in 10.6.

danilocampos 16y ago
Really? With bindings you get to write so much less glue code for labels, button states and other UI widgets. It's a dramatic time saver for UI minutiae.
- Zev 16y ago
  I've never found myself wishing for bindings on the iPhone. Maybe when I'm using Core Data, but thats not too often. And even then, its relatively easy and quick to abstract it all away. I want GC on the iPhone. Not for the GC itself, just so Apple will make NSPointerArray, NSHashTable and NSMapTable part of the public API.
- jsolson 16y ago
  I actually do like them for labels, button states, and other what I'll call "scalar" widgets. For collections, though, I feel like they're more likely to get you into trouble than to actually solve your problems. I think you could do something substantially less complicated/powerful than bindings for the cases that bindings handle well, though, and I'd rather Apple did some innovating there than bring bindings over to iOS. I'm also with the other folk who would much prefer to see Garbage Collection first. I rarely get into trouble with the reference counting system, but when I do it usually takes me forever to track down why my app is crashing without a single line of code written by me in the stack trace. Usually it's because I assigned an autoreleased value to an ivar in an init method while failing to retain it (a stupid mistake that I still make once every few months even after 5 years of Cocoa/Cocoa Touch work).
bonaldi 16y ago
I have seen bindings running on iOS, and it has massive potential, especially for areas like live updating of on-screen table rows etc. Fully expect them there soon. Will be astonished if they get deprecated on desktop, too. Value is far too high.

by jsolson 16y ago

danilocampos 16y ago

Really? With bindings you get to write so much less glue code for labels, button states and other UI widgets. It's a dramatic time saver for UI minutiae.

Zev 16y ago
I've never found myself wishing for bindings on the iPhone. Maybe when I'm using Core Data, but thats not too often. And even then, its relatively easy and quick to abstract it all away. I want GC on the iPhone. Not for the GC itself, just so Apple will make NSPointerArray, NSHashTable and NSMapTable part of the public API.
jsolson 16y ago
I actually do like them for labels, button states, and other what I'll call "scalar" widgets. For collections, though, I feel like they're more likely to get you into trouble than to actually solve your problems. I think you could do something substantially less complicated/powerful than bindings for the cases that bindings handle well, though, and I'd rather Apple did some innovating there than bring bindings over to iOS. I'm also with the other folk who would much prefer to see Garbage Collection first. I rarely get into trouble with the reference counting system, but when I do it usually takes me forever to track down why my app is crashing without a single line of code written by me in the stack trace. Usually it's because I assigned an autoreleased value to an ivar in an init method while failing to retain it (a stupid mistake that I still make once every few months even after 5 years of Cocoa/Cocoa Touch work).

bonaldi 16y ago

I have seen bindings running on iOS, and it has massive potential, especially for areas like live updating of on-screen table rows etc. Fully expect them there soon. Will be astonished if they get deprecated on desktop, too. Value is far too high.