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

ben hockey neonstalwart at gmail.com
Thu Mar 10 16:54:30 EST 2011

partial response inline

On 3/10/2011 4:16 PM, Rawld Gill 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.
actually, this is not correct.  if you look at the current state of 
dojo.stateful.watch, it notifies on all calls to set.  hence the subject 
line of this thread.  it was accidentally reverted to this behavior as 
part of r23032.

> 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)
notifies all watchers any time the property is set regardless of a 
change in value.

> 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.
see above - implementation and docs do not align in the way you're 

there is some more discussion in 
<http://bugs.dojotoolkit.org/ticket/12399#comment:8> if you're interested.
> 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
>> _______________________________________________
>> dojo-contributors mailing list
>> 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/20110310/066e00b7/attachment.htm 

More information about the dojo-contributors mailing list