[dojo-contributors] defineClass

Tom Trenka ttrenka at gmail.com
Thu Apr 27 10:17:36 EDT 2006


Let me amend that vote real quick--I will vote a very strong -1 if the
intention is to turn around and make this a fundamental part of the Dojo
structure.  If this were to be added to lang as an optional thing--and one
that core libraries in Dojo itself didn't rely on--then I'd be neutral on
it.

trt

On 4/27/06, Tom Trenka <ttrenka at gmail.com> wrote:
>
> 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.extendsand
> 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/cc7b2fb8/attachment.htm 


More information about the dojo-contributors mailing list