Object.observe withdrawn from TC39

Re:Object.observe withdrawn from TC39 by arcticbull on Monday November 02, 2015 @11:52PM (#10497629)

I've interacted with KVO for years before iOS ever came out and I can honestly say it's just the worst. It's stringly typed with zero compile-time validation so as soon as your model key paths change your app breaks in the least expected places. Then throw bindings in the mix and your key path constants are in your nibs too! God have mercy.

I'm not the least bit surprised they discarded bindings in iOS, then (effectively) discarded KVO in Swift.

Next time, try playing with creating an observer protocol:

  @protocol MyThingObserver
  @optional
  - (void)myThing:(MyThing *)thing didChangeIntegerValue:(NSUInteger)newValue;
  - (void)numberOfItemsDidChangeInThing:(MyThing *)thing;
  @end

Then you have strong typing, compile-time validation, additional context, and plays much nicer with the land of tomorrow (Swift).

Coupled with immutable value types, you're going to make your own life way easier, I promise.

[ Parent | on HN ]

Re:Object.observe withdrawn from TC39 by tolmasky on Tuesday November 03, 2015 @12:26AM (#10497744)

I have no interest in returning to any programming model that fundamentally revolves around complex sync-up code (also, yes we "tried" this aplenty long before KVO/bindings).

As I mentioned in my previous post, I felt KVO was a really interesting design path to be sure, but I agree with you it had its fair share of issues. That being said, observer patterns are just incremental improvements on this. Conceptually its still the same: figuring out ways of getting different parts of a system to eventually "settle" on the same value. Sure, strict typing and whatnot can make this safer, but its ultimately a lot of code that has no real connection to the actual problem your program is trying to solve.

Personally I find immutable everything types (through persistent data structures) combined with immediate mode programming for rendering has more or less taken away the cognitive overhead I used to have around this set of "problems". You have a model, that can lead to a new model in the future. You then have a render function that is a function of this model. Its completely deterministic, there is only one path things can go down, you can grab the state of your program at any time and keep re-rendering it to figure out whats going on -- there's no "implicit" conglomeration of state through the value of all the free variables in your program at any particular point in time and their knowledge of each other.

If I were to return to iOS programming today, I'd probably give React Native a stab. To me tomorrow land is being able to change code and see it live update without recompile or provisioning profiles or what have you.

[ Parent | on HN ]