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.
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.
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?
-- 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]
