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

Rawld Gill rgill at altoviso.com
Thu Mar 10 16:16:10 EST 2011


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
> 
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors


More information about the dojo-contributors mailing list