Just to confirm, prototypes and constructor functions are bound together with the circular dependency of constructor.prototype.constructor === constructor.
This means there the same thing and whether you want to call you "class-like" object the constructoor or the prototype is a matter of style and personal preference. The thing I objected to was // your initializing the prototype instance rather then just instantiating it. // a sub class is not an instance of a super class, it merely inherits from it. There's a subtle distinction constructor.prototype = new Parent(); This can be avoided by creating a custom construct like you did with `myNamespace.inherit`, of course I will object to that because ES5 has a native construct (Object.create) that will do that for you. The argument that you should be emulating ES5 rather then using your own custom sugar for inheritance is slightly more sensible because the former is future proof and standardized. Other then that there's nothing wrong with constructor functions On Wed, Oct 26, 2011 at 2:21 PM, Scott Sauyet <[email protected]>wrote: > Jake Verbaten wrote: > > Scott Sauyet wrote: > >> Jake Verbaten wrote: > > >> I don't want to have to wade my way through code to find that one > >> developer saw another's use of `Object.create`, looked it up in the > >> specs, saw the great features that would allow them to add, say, a non- > >> enumerable property, incorporated that in the project, found it worked > >> fine in their quick tests, even noted in the console that the property > >> was not enumerated, and declared themselves done, because it will be > >> weeks or months later that I'm coming in with an odd use case that > >> exposes a bug, only in IE<9, because that property was in fact > >> enumerable. > > > > What your describing is a) a bad developer and b) how your team failed to > > use code reviews, c) how your team failed to have unit tests. > > I didn't say this had happened. But this is the sort of thing I have > seen on larger teams, even where most of the developers are competent, > the team either pairs or does other forms of code review, and the code > has an excellent set of unit tests. When some of these conditions > fail, it's even more likely. > > > >> That's why when working with larger teams, I try to use shims only > >> when they can completely do the job of replacing that which they shim. > > > > Meh on a large project that uses javascript you before hand choose to > either > > use ES3 or ES5. Then every developer sits down and realises the > limitations > > of the cross browser shim that is ES5-shim. Of course I dont see why you > > would choose ES3. > > > > The same with your DOM-shim / abstraction of choice. > > Have you ever worked on a large team? Especially one with more than > twenty developers? We have more than twenty people in our UI code, > and many more doing our (non-JS) back end. > > When I joined my current project, there were already six or eight > developers working on the JS, and probably not one of them had ever > heard of ECMAScript. Since then, I've been able to hire more > experienced and more competent developers. But many of those original > ones are still around, and they've become fairly adept at JS. We have > some team members who are heavy-hitters, and they get the more > challenging assignments. > > We probably have four or five different types of inheritance schemes > going on in the application now, although we're slowly reducing that > set. My examples using Object.create was not an actual problem we > faced, since we don't use Object.create. Those of us who know it's > available have not looked to introduce the shims, because we haven't > found the need. But it is the type of problem I can easily imagine > facing. > > > I'm still curious if you have a response to this: > > >>> If you take a look at my pd project you see I really dislike handling > >>> `new <Function>` or constructor functions by hand. > > > >> Why do you object? I've never shared this distaste. > > > > >> var Shape = function() { /*...*/} > >> var Circle = function() {/*...*/} > >> myNamespace.inherit(Shape, Circle); > > [ ... ] > >> Do you also find this pattern inelegant? > > > > Yes, > > > > var Shape = { ... }; > > var Circle = Object.make(Shape, { > > ... > > }); > > And presumably Shape and Circle serve as prototypes and pseudo-classes > for shapes and circles? While I understand this style, I've never > seen any particular reason to prefer it to what's been the standard JS > mechanism for a long time. It's not that I object. But this seems, > as you say, just a matter of style. You earlier seemed to be arguing > that others are doing it wrong, not that you simply prefer a different > style. Have I been reading your posts wrong? > > > > However my object is a matter of style. I really like prototypes as > > classes<http://www.2ality.com/2011/06/prototypes-as-classes.html> > > > > I also prefer to treat `.constructor` as the constructor function and not > > some other one. > > It's clear that you do prefer it. Can you present any cogent > arguments as to why others should also prefer it? > > -- Scott > > -- > 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]
