[dojo-contributors] defineClass

Tom Trenka ttrenka at gmail.com
Thu Apr 27 12:26:39 EDT 2006


Scott,

After discussing this with Dustin and going a hunting in the source, it
looks like what you're proposing is a replacement and not an addition.  If
that's the case then I'll stay
neutral on the topic, and my apologies for being a butthead.

I strongly disagree with the use of a reference to a super class, but since
it looks like that's been living in dojo.inherits for a while, I guess I'll
deal :)

trt

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


More information about the dojo-contributors mailing list