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

Bill Keese bill at dojotoolkit.org
Thu Mar 10 22:49:26 EST 2011


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
> >
> > _______________________________________________
> > 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/20110311/5ffdfbb5/attachment-0001.htm 


More information about the dojo-contributors mailing list