[dojo-contributors] defineClass

Tom Trenka ttrenka at gmail.com
Thu Apr 27 10:16:15 EDT 2006


No worries on the crap typing, we all suffer from it :)

Something I'd want to point out real quick--dojo.extends isn't required at
all for object prototyping.  I'd actually objected to both dojo.extends and
dojo.inherits (if somewhat privately); both mask straight up inheritance
processes for not a huge amount of gain (although extends is a bit different
in a subtle way).

I'm for reducing code bloat but not in a way that hides fundamental language
constructs.  What this will end up doing (and what dojo.inherits,
dojo.extends, dojo.provide and dojo.require do) is make it much less likely
a developer would try to grab several different toolkits to do the job that
they need to do, and much more likely to either try to deal with (perceived)
weaknesses in Dojo (*cough* animations for now *cough*) or simply choose to
use a different, more inclusive toolkit (*cough* Prototype *cough*--which
isn't that inclusive but *appears* to be so).  Call me paranoid but this is
the kind of practice that killed the DynAPI and makes toolkits like the
DomAPI less attractive.  I know we have quite a bit more community support,
but in the end IMHO built-in coding style prejudices are a bad thing.

I know I'll be outvoted on this one, but I'll still put in my -1.

trt

(to give an example, I know of at least one very prominent company that will
not even look at Dojo at this point because of some of the deep down core
dependencies, like what this would add).

On 4/27/06, Scott J. Miles <sjmiles at turboajax.com> wrote:
>
> Sorry for the crap typing in that last missive.
>
> s/night/nigh
>  s/prop: "value";/prop: "value"
>
> I wanted to add that Alex's defineWidget does similar stuff. So maybe
> there is another helpful analogy there. Also, by rewriting defineWidget in
> terms of defineClass, I reduced the net number of lines needed to add
> defineClass.
>
> Overall IMO defineClass will be a good soldier in the war against code
> bloat.
>
> Scott
>
>  ------------------------------
>  *From:* dojo-contributors-bounces at dojotoolkit.org [mailto:
> dojo-contributors-bounces at dojotoolkit.org] *On Behalf Of *Scott J. Miles
> *Sent:* Wednesday, April 26, 2006 11:50 PM
> *To:* 'dojo dev.'
> *Subject:* RE: [dojo-contributors] defineClass
>
>  >> using this over more traditional methods
>
> These *are* the traditional methods. I'm simply reducing boilerplate.
>
> Analogy: dojo.extends is a helper method which allows setting up a
> prototype with a minimum of pain. Similarly dojo.defineClass is just a
> helper method that allows standard JS stuff to be expressed in a compact
> manner.
>
> The only non-factory concept is the idea of a non-constructor initializer
> method.
>
> >> Can you give us a use case or two where there would be a definite
> advantage to using this over more traditional methods?
>
> Without define class:
>
>     myClass = function() {
>      mySuperclass.call(this); // uh oh, don't forget this or your class is
> b0rken
>     }
>
>     dojo.inherits(myClass, mySuperclass);
>
>     dojo.lang.extend(myClass, {
>        prop: "value"
>     });
>
> With defineClass:
>
>     dojo.defineClass('myClass', mySuperclass, {
>      prop: "value";
>     });
>
> More compact, easier to understand, no worries about forgetting to call
> superclass constructor.
> Additionally, in the constructor you can have a problem because you might
> be instantiating an object or you might be creating a prototype for
> inheriting from myClass. Separating an instance initializer from the
> constructor solves this problem night transparently.
>
> Regards,
> Scott J. Miles
> TurboAjax Group
> http://www.turboajax.com
>  ------------------------------
> *From:* dojo-contributors-bounces at dojotoolkit.org [mailto:
> dojo-contributors-bounces at dojotoolkit.org] *On Behalf Of *Tom Trenka
> *Sent:* Wednesday, April 26, 2006 10:24 PM
> *To:* dojo dev.
> *Subject:* Re: [dojo-contributors] defineClass
>
> I don't really mean to continually butt heads here, but I'm still failing
> to see the point/need for this?  It seems like it's an alternate way of
> creating objects in Javascript, except instead of doing it the way the
> language was designed there's basically a number of additional properties
> that are added for the sole purpose of being able to get at the immediate
> parent...
>
> I don't have a problem with having a function that can take an
> initialization function and use that in conjunction with a constructor; that
> seems like a pretty good mechanism for deserialization from custom
> serialization formats in the very least.  But this looks an awful lot to me
> like it's trying to force JS to do something that's more common in other
> languages.
>
> Can you give us a use case or two where there would be a definite
> advantage to using this over more traditional methods?
>
> trt
>
> On 4/25/06, Scott J. Miles <sjmiles at dojotoolkit.org> wrote:
> >
> > We discussed some weeks ago a helper function to define/extend classes.
> > I
> > propose a function to do that, interested parties can review it here:
> >
> > http://itch.homeip.net/turboajax/defineClass.html
> >
> > Scott
> >
> > P.S. It's really quite simple. I only made a separate page because I
> > figured
> > Outlook would mangle the formatting, I couldn't get the Wiki to
> > cooperate,
> > and I wanted to be as clear as possible.
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.4.6/324 - Release Date: 4/25/2006
>
> --
> No virus found in this incoming message.
>
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.4.6/324 - Release Date: 4/25/2006
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.4.6/324 - Release Date: 4/25/2006
>
> _______________________________________________
> 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/20060427/2087e8df/attachment.htm 


More information about the dojo-contributors mailing list