[dojo-contributors] Improved mixin semantics

Jared Jurkiewicz jared.jurkiewicz at gmail.com
Thu Aug 9 09:15:28 EDT 2007


It's not just dijit that's affected by this change.   All
dojo.dataDatastores are also affected, as well as several modules in
dojox.  I know
you're trying to improve Declare and that's certainly a good thing ... but
this was a very poor time to be doing it.  Dojo 0.9 was supposed to be
code/bug done by this friday (eg tomorrow).  And now there is a pile of
deprecation warnings that have to be fixed across all the projects.

Sincerely,
-- Jared Jurkiewicz


On 8/8/07, Scott J. Miles <sjmiles at turboajax.com> wrote:
>
> Should be mostly better now, as of [10032]. Sorry about that.
>
> Note that Dijit is throwing deprecation warnings because of declare
> syntax. I will fix those once I get a sense that the new declare isn't
> breaking something else.
>
> Regards,
> Scott J. Miles
> TurboAjax Group
> http://www.turboajax.com
>
> Scott J. Miles wrote:
> > Argh, I may have broken Dijit with this commit. Mea culpa. I'm on it.
> >
> > Regards,
> > Scott J. Miles
> > TurboAjax Group
> > http://www.turboajax.com
> >
> > Scott J. Miles wrote:
> >> In [10026] I've committed a refactored declare.js that has improved,
> >> hopefully robust, mixin semantics.
> >>
> >> "inherited" should now work inside of mixin classes, and to travel into
> >> and out of mixin trees.
> >>
> >> The basic syntax for inherited is like so:
> >>
> >> dojo.declare("bar", [base, mixin, mixin2], {
> >>    foo: function() {
> >>      this.inherited("foo", arguments);
> >>    }
> >> });
> >>
> >> Note that the first argument must be the name of the function and the
> >> second argument must literally be 'arguments'. More on this below.
> >>
> >> The inherited call will seek ancestral 'foo' in right-to-left order.
> >> Iow, first it looks in mixin2 (and up through it's ancestry) and then
> >> into mixin, and finally base.
> >>
> >> I added a basic test in the test suite, hopefully you guys can bang on
> >> it and see if there are any flaws (ahem, see where the flaws are).
> >> Internally we've thrown some crazy structures at it and so far so good.
> >>
> >> Wrt to the signature, I realize that it's odd, but it makes the magic
> >> happen.
> >>
> >> Note that in Dean's Base2 he's solved this problem by RegEx'ing method
> >> code to detect the superclass call and then wrapping methods in
> closures
> >> as needed to setup the necessary info. This is clever as usual and
> makes
> >> most of the work into one-time preprocessing.
> >>
> >> The benefit of declare is that it works regardless of how a particular
> >> method got into your class. That is, you can poke methods directly into
> >> prototypes or instances and 'inherited' should still work properly.
> >>
> >> This was all a lot of work, so if you hate declare in general, or
> simply
> >> would prefer some other tack, please start a new thread and give your
> >> objective reasoning. I will be grateful as that will keep my head from
> >> exploding. :)
> >>
> >> Regards,
> >> Scott J. Miles
> >> TurboAjax Group
> >> http://www.turboajax.com
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20070809/94ced1e8/attachment.htm 


More information about the dojo-contributors mailing list