Object.create clashes with native Object.create about sugar HOT 8 CLOSED

You've discovered one of a handful of thorny areas with Sugar. I ran across that spec somewhat late in the game and immediately noticed the clash. I also noticed how goofy it was in that it's attempting to do what the standard constructor should, and in an inverted, counterintuitive way with the prototype object as the first param. It's going to require a bit of thought but I will say that there are no sacred cows, not even native ECMA ones, and I may be able to live with a single clash.

In the meantime, any suggestions for a name? "Make" just doesn't do it for me. Also there is Date.create as well. I would like to rename to maintain the parallel naming.

from sugar.

FWIW I also considered "extend", as the method in fact does create an object with extended methods... I don't like that name, however, because it's ambiguous in sounding similar to the Object.merge method.

from sugar.

"but I will say that there are no sacred cows, not even native ECMA ones, and I may be able to live with a single clash."

Object.create is the best part of ES5. It's a huge improvement over new and .prototype and really gives us a solid prototypical OO API.

This really needs to change.

from sugar.

Perhaps Object.build is a little better?

I'm afraid I have to disagree with the statement about "no sacred cows, not even native ECMA ones, and I may be able to live with a single clash.". I think that wherever possible the native methods should be left alone, by all means provide a shim when they're not available but always leave the behaviour etc intact.

Having a look at the code for Object.create it appears to be creating a Hash, why not just have Hash.create, or even new Hash?

Interesting project though, I started on something similar a while back but didn't quite get as far - http://olivernn.github.com/supplement.js/.

from sugar.

@olivernn This in the end will be a hard-line for me and I may end up simply disagreeing. However we're probably working toward the same goal more than we think. Object.build is not a bad compromise... let me give it some thought.

@Raynos I'm willing to believe you but can you please give examples? How is Object.create the best part? (that's quite a statement). In other words, how would you use it?

from sugar.

@andrewplummer

prototypical OO in JS

more prototypical OO in JS

If you want further details feel free to say so.

from sugar.

Okay, after thinking about it, I'm with you guys on this one. The fact is that Object.create wasn't a very accurate name to begin with, as it's not simply acting like the constructor but returning a Hash class that has extended methods on it. I'm very much against the terminology hash though when it comes to JS because it tends to raise more questions for those unfamiliar with the term. I also didn't like extend due to it's confusion with merge in other frameworks. So I've settled on extended as a balance. It's more correct in what it's doing, yet is still intuitive and reads well.

The greater point I guess is that Object.create is now left alone again, and is released in v0.9.1.
Scrambled to get this one out before people settled into using create.

OK time to get some sleep...

from sugar.

@andrewplummer Good work, you reacted to community feedback well and still kept to your own vision of sugarjs.

from sugar.