[dojo-contributors] dojo.Stateful - long live r23032!

Rahul Akolkar rahul.akolkar at gmail.com
Fri Mar 11 16:27:42 EST 2011


2011/3/11 ben hockey <neonstalwart at gmail.com>:
> in various comments in #11738 i mentioned a few cases where values which are
> arrays and dates (and it also applies to objects) may change value/state wrt
> to what they represent (ie add another item to the array, change the time
> for a date, add another property to an object or change an existing
> property) but calling set will not fire watch because oldValue === newValue
> in these cases.  alternatively, i may have an oldValue that is the object {
> a: 'foo' } and a newValue that is another object but is { a: 'foo' } and in
> this case watch will be called since oldValue !== newValue but semantically,
> the 2 values are equal.
>
> i also mentioned in a response to rawld on this thread that connecting to
> set is not quite the same as a watch callback because the callback to watch
> will be passed the oldValue and newValue whereas connecting to set will only
> give you the newValue.  in this way connecting to set is not the same as
> adding a watch callback.
>
> my main objection is that the one definition of "equal" (equal by identity)
> has been pre-determined to be the right choice in all cases.  imo this is a
> premature optimization and it should be left to develppers to determine what
> is "equal" and not something imposed by a library.
<snip/>

+1 to the above.

-Rahul


>  my proposal to change
> watch to have a 3rd param to prevent the callback from firing when oldValue
> === newValue would give developers a chance to opt-in to an option that will
> prevent their callback from being called when oldValue === newValue.  i also
> believe that the granularity of this option is a good choice since it is an
> option per callback.
>
> my proposal deliberately avoids changing the existing behavior of
> dojo.Stateful - this is why i chose to have a truthy value for the 3rd param
> mean that you want the behavior that is different from the current
> implementation.  for anyone who has implemented code based on the current
> implementation of dojo.Stateful, it doesn't matter what the documentation
> says, to make their code work, they have had to deal with the current
> implementation of dojo.Stateful.  (fwiw, there has never been a release of
> an implementation of dojo.Stateful that has had a behavior different to the
> existing behavior).  i could live with the semantics of the 3rd param being
> the opposite but i've suggested what i think is the better option based on
> maintaining the same behavior as previous releases.
>
> ben...
>
> On 3/10/2011 10:49 PM, Bill Keese wrote:
>
> Agreed, let's re-fix dojo.Stateful to work according to it's spec.
> Ben suggested adding a flag to watch() to notify on all set, even setting to
> the same value.   I could live with that but I'd want to see more evidence
> of when it's useful.   I emphasize the word evidence.    I understand it's a
> little more convenient than connecting to set(), but only by one line:
> dojo.connect(obj, "set", function(name, val){
>     if(name == "foo") { ... }
> });
>
>
> On Fri, Mar 11, 2011 at 6:16 AM, Rawld Gill <rgill at altoviso.com> wrote:
>>
>> On Thursday 10 March 2011 06:31:47 Rahul Akolkar wrote:
>> > On Wed, Mar 9, 2011 at 11:48 PM, Bill Keese <bill at dojotoolkit.org>
>> > wrote:
>> > > We didn't agree to this at the meeting (or at any other time).
>> >
>> > <snip/>
>> >
>> > Correct, its MO -- tautologically, I disagree with anyone who
>> > disagrees with me on something as fundamental as this :-)
>>
>> Why is it fundamental? Because you say so?
>>
>> Let's try some engineering reasoning on this thread for a moment:
>>
>> 1. The documentation for dojo.stateful .watch says:
>>
>> "Watches a property for changes"
>>
>> and
>>
>> "The function to execute when the property changes."
>>
>> So, currently, dojo.stateful.watch's specification (the docs) and
>> implementation (the code) are inconsistent.
>>
>> 2. The client is not watching set() applications, it is
>> watching an attribute value (attribute, as in component of an aggregate,
>> not
>> HTML attribute). While not provable, there is strong, *rational* evidence
>> for
>> this statement:
>>
>>  * watch takes an argument to say which attribute value it is watching.
>>
>>  * The alternative definition of watch--stateful indiscriminately signals
>> all
>> set() applications--implies watch does nothing more or different than
>> connect()...which we already have...thus adding the complexity of an
>> additional API for no gain.
>>
>>  * To signal a no-op on the attribute value is, at a minimum, inefficient
>> (which Rahul concedes). At worse, it will break handler code that contains
>> cycles (e.g., handler of set(A, x) calls set(B, y); handler of set(B, y)
>> calls
>> set(A, x)).
>>
>> 3. There is a simple solution for Rahul's problem as Bill suggested in the
>> meeting: connect to set(). I have not heard a reason why this is
>> unacceptable.
>>
>> 4. APIs like stateful are quite common place. I've seen them in many
>> object
>> systems in many languages. I'm fairly certain that most do not signal on
>> no-
>> ops  (e.g., http://msdn.microsoft.com/en-
>> us/library/ms692638%28v=VS.85%29.aspx)
>>
>> On the other side of the argument, we have a use case, namely Rahul's,
>> that
>> would like stateful to signal on all set() applications. A use case is
>> important. However, I would really like to see a genuine attempt at Bill's
>> proposed solution. If this fails, maybe we can learn something about a
>> weakness in connect() and fix that.
>>
>> I save my *opinion* for last: dojo.stateful.watch docs seem fundamentally
>> correct, which make the implementation incorrect.
>>
>> Best,
>> Rawld
>>
>> >
>> > The current (and also original, which is worth a lot) dojo.Stateful
>> > behavior is superior. Reasons are in #12399, IRC log from yesterday's
>> > meeting and below. This is also the behavior in v1.5 and v1.6.
>> >
>> > I don't see how any of this can be discounted. As an avid Dojo user, I
>> > therefore strongly object to changing related dojo.Stateful behavior
>> > beyond r23032. Which brings us to the subject of this email.
>> >
>> > -Rahul
>> >
>> > > On Thu, Mar 10, 2011 at 12:57 PM, Rahul Akolkar
>> > > <rahul.akolkar at gmail.com>
>> > >
>> > > wrote:
>> > >> Kris,
>> > >>
>> > >> Just got a chance to look at said rev, so to clarify -- lets keep
>> > >> Stateful behavior the way it is ATM.
>> > >>
>> > >> Rationale is simple: application can trivially ignore equal values
>> > >> now
>> > >> if it so chooses, whereas there is no way for application to override
>> > >> r{22883-23032} behavior.
>> > >>
>> > >> Cheers,
>> > >> -Rahul
>> >


More information about the dojo-contributors mailing list