> > Thus, the following can not be done with Object.create().
oh really? http://jsfiddle.net/NsxHR/ On Mon, Oct 24, 2011 at 6:04 PM, Bemi Faison <[email protected]> wrote: > There is one reason to extend a prototype with a constructor: chaining. > Remember that setting the prototype to anything but the result of a "new" > statement, blows the original prototype away - breaking the chain. Thus, > the following can not be done with Object.create(). > > function Child() {} > Child.prototype.act = 'silly'; > > function Teen() {} > Teen.prototype = new Child(); > Teen.prototype.speech = 'angry'; > > function Adult() {} > Adult.prototype = new Teen(); > Adult.prototype.speech = 'mature'; > > var you = new Adult(); > console.log(you.act); // "silly" > > Besides being able to see the .act member, I can now impact the prototype > of an Adult instance, by editing the prototypes of any chained constructor. > The same might be possible with object composition frameworks - a.k.a. "the > Crockford method" - but not without a lot of ridiculous overhead and > nightmarish concurrency issues. Frankly, I'm afraid that classical > inheritance models have overshadowed this powerful feature of JavaScript > object oriented programming. > > You may not have a need for this kind of flexibility, and there are plenty > of tried and true object-composition frameworks out there... But you just > can't beat the native prototype chain! > > Regarding the constructor that's firing twice: the constructor is poorly > designed. Principally, constructors should do no more than define > themselves. In this sense, their impact is isolated and less dangerous than > a constructor which manipulates objects outside itself (like the DOM or > higher-scoped variables). Again, due to the pervasiveness of classical > programming models, many developers think everything must be a Class - > including controller functions - which isn't appropriate or useful. > > The way I see it, there are constructor, utility, and controller > functions. The simplest distinction is that constructors have optional > arguments, utility functions return something, and controller functions do > not return anything; all other aspects are mutually exclusive (e.g., > utility functions can take arguments). > > Keeping these simple rules in mind, developers could create and use > functions better. In the case of the original posters issue, they would no > longer attempt to instantiate what is (essentially) a controller function, > or they would break out such behavior into a method (as suggested by Scott > Sauyet's post). > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected] > -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
