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

ben hockey neonstalwart at gmail.com
Fri Mar 11 10:06:16 EST 2011

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.  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.


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 
> <mailto: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 <mailto: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 <mailto: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 <tel:22883-23032>} behavior.
>     > >>
>     > >> Cheers,
>     > >> -Rahul
>     >
>     > _______________________________________________
>     > dojo-contributors mailing list
>     > dojo-contributors at mail.dojotoolkit.org
>     <mailto:dojo-contributors at mail.dojotoolkit.org>
>     > http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>     _______________________________________________
>     dojo-contributors mailing list
>     dojo-contributors at mail.dojotoolkit.org
>     <mailto:dojo-contributors at mail.dojotoolkit.org>
>     http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110311/51c4ea4e/attachment-0001.htm 

More information about the dojo-contributors mailing list