On Tue, Oct 25, 2011 at 6:05 PM, Scott Sauyet <[email protected]>wrote:
> Jake Verbaten wrote: > > Scott Sauyet wrote: > >> Jake Verbaten wrote: > >>> Scott Sauyet wrote: > > > >>>> I simply have never been quite certain when I can depend upon > >>>> Object.create being present and functioning correctly. And I'm wary > >>>> of shims which can never do what the original is supposed to do. > >>>> [ ... ] > >>> ES5 shim <https://github.com/kriskowal/es5-shim> will shim out a > >>> sensible subset of ES5. [ ... ] > >> One person's sensible subset may be another's hopelessly crippled > >> implementation. [ ... ] But I'm working on a large project now with > >> many team members who might well expect it to work too much like the > >> ES5 spec. [ ... ] > > > > Meh, the documentaiton on the README says which shims do not work. Any > > competent team member should be able to "know" the sensible subset of ES5 > > from reading that. > > If you work with a large team where all the developers read the > documentation of tools their teammates introduce to the system, then I > envy you! > > 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. > > 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. > > When working on my own projects, or anything with only a few > developers, I have no issues doing this. > > >>> however we are suggesting you use Object.create(proto) not > >>> Object.create(proto, pd) the former works completely cross browser. > > > >> I'm curious if you object to the formulation above, which of course is > >> doing much the same as any of the Object.create shims. [ ... ] > > > > 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. > > > As far as I can see your code will work but it feels really ugly and > > un-elegant. > > It's not really my code. It's a pattern that's been around the JS > world a long time. And I simply don't see how it's inelegant. > > If you notice, the shim under discussion uses at its core of the > `Object.create` function the following: > > var Type = function () {}; > Type.prototype = prototype; > object = new Type(); > > > > I'd personally just call that function you normally call `inherit` > > Object.create (except the latter operates on objects not constructor > > functions). > > But notice that I use it to say that one constructor is derived from > another, not that one object is derived from another. I might use it > like this: > > var Shape = function() { /*...*/} > var Circle = function() {/*...*/} > myNamespace.inherit(Shape, Circle); > > Other implementations I've used do something more like: > > var Shape = function() {/*...*/} > var Circle = myNamespace.inherit(Shape, { > init: function() {/* pseudo-constructor function */}, > getRadius: function() {/*...*/} > /*, ...*/ > }); > In either case, the end result is to have the prototype of the parent > constructor on the prototype chain of the child constructor. > > Do you also find this pattern inelegant? > Yes, var Shape = { ... }; var Circle = Object.make(Shape, { ... }); 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. > > -- 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]
