[MacRuby] #409: Attribute setter should be accepted as KVO setter
#409: Attribute setter should be accepted as KVO setter ---------------------------------+------------------------------------------ Reporter: neeracher@… | Owner: lsansonetti@… Type: enhancement | Status: new Priority: minor | Milestone: Component: MacRuby | Keywords: ---------------------------------+------------------------------------------ MacRuby rev 2903: {{{ class A attr_reader :a, :b def setA(value) @a = value end def b=(value) @b = value end end a = A.new a.setValue("hey", forKey:"a") p a a.setValue("yo", forKey:"b") p.a }}} It would be nice if the ruby style setter worked for KVO as well. -- Ticket URL: <http://www.macruby.org/trac/ticket/409> MacRuby <http://macruby.org/>
#409: Attribute setter should be accepted as KVO setter ---------------------------------+------------------------------------------ Reporter: neeracher@… | Owner: lsansonetti@… Type: enhancement | Status: new Priority: minor | Milestone: Component: MacRuby | Keywords: ---------------------------------+------------------------------------------ Comment(by dylan@…): *poke* I just ran into this one and traced it down. Any updates ? I've attached a project that shows a naive implementation with bindings that shows how someone could get into trouble with this. I think this is a little more severe than it appears at first glance. It violates the principle of least surprise in a big way; even something a simple as adapting example code to a new Mac interface will run afoul of this pretty quickly. Even if you're familiar with both Ruby and ObjC this generates some confusion since you can no longer use idiomatic ruby to change your model if you want it bound to the UI at any future date. You currently have to get used to always using the ObjC setValue way. If you're not familiar with both you're going to be scratching your head for a while. This is also insidious since your model unit tests will pass and only the less easily testable UI will fail, unless you set up explicit bindings tests for each property. That said, this may not be as simple a fix as it appears. My gut feeling was to override attr_accessor and writer to generate a value= method that just calls setValue. This works 95% of the time, but gets murky when you want to create a custom setter. Which do you override ? Do you always have to call setValue from your value= method ? How should it be documented if that's the case ? Of course, you still have that confusion the way it exists now. Going to implement value= and then finding that your bindings don't call that method, for instance. -- Ticket URL: <http://www.macruby.org/trac/ticket/409#comment:1> MacRuby <http://macruby.org/>
#409: Attribute setter should be accepted as KVO setter ---------------------------------+------------------------------------------ Reporter: neeracher@… | Owner: lsansonetti@… Type: enhancement | Status: new Priority: minor | Milestone: Component: MacRuby | Keywords: ---------------------------------+------------------------------------------ Comment(by lsansonetti@…): I am not 100% confident with your proposal either. I share your concern about overriding custom setters. But it may be better than what we currently have. -- Ticket URL: <http://www.macruby.org/trac/ticket/409#comment:2> MacRuby <http://macruby.org/>
#409: Attribute setter should be accepted as KVO setter ---------------------------------+------------------------------------------ Reporter: neeracher@… | Owner: lsansonetti@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: MacRuby | Resolution: wontfix Keywords: | ---------------------------------+------------------------------------------ Changes (by lsansonetti@…): * status: new => closed * resolution: => wontfix Comment: As of trunk, using #attr_writer or #attr_accessor will generate a KVO setter automatically (so, changing your snippet to do `attr_writer :b' makes it work). Defining #foo= will not. I think this is a good deal, we don't want too much magic. -- Ticket URL: <http://www.macruby.org/trac/ticket/409#comment:3> MacRuby <http://macruby.org/>
participants (1)
-
MacRuby