Function.create

[Alex Russell]

As a meta-point, I'd like for us to stop adding ".create()" functions, or at least stop adding them without syntax. The early precedent -- document.create() -- is an accident of C++ object ownership semantics from a DOM that often seems to be designed to be explicitly *un*-idiomatic. We have an allocator form (new) and we have factory functions (Array())…the third creation mechanism seems wholly incongruous.

Regards

On Sep 24, 2011, at 10:40 AM, Oliver Hunt wrote:

> I believe the goal is to eventually deprecate the magic of __proto__ as mutating the prototype of an object makes it difficult to reason about a program and supporting the mutation of an object's prototype also has a reasonably significant performance cost -- the exact time and place (and extent) of the cost is engine specific, but certainly it is not free.
> 
> That said I'm not yet convinced we'll ever be able to kill it off :-/
> 
> --Oliver
> 
> 
> On Sep 24, 2011, at 10:30 AM, Xavier MONTILLET wrote:
> 
>> I don't get the difference between the proto operator and some
>> setPrototype method that could be added (or the actual __proto__
>> property)...
>> 
>> On Sat, Sep 24, 2011 at 6:03 PM, David Bruant <david.bruant at labri.fr> wrote:
>>> Le 24/09/2011 15:33, Jake Verbaten a écrit :
>>>> There is no standardized way to create a new function with a prototype
>>>> which is not Function.prototype.
>>>> 
>>>> I propose Function.create
>>>> 
>>>>    /*
>>>>      Creates a new function whose prototype is proto.
>>>>      The function body is the same as the function fbody.
>>>>      The hash of propertydescriptors props is passed to
>>>> defineproperties just like
>>>>      Object.create does.
>>>>    */
>>>>    Function.create = (function() {
>>>>      var functionBody = function _getFunctionBody(f) {
>>>>        return f.toString().replace(/.+\{/, "").replace(/\}$/, "");
>>>>      };
>>>>      var letters = "abcdefghijklmnopqrstuvwxyz".split("");
>>>> 
>>>>      return function _create(proto, fbody, props) {
>>>>        var parameters = letters.slice(0, fbody.length);
>>>>        parameters.push(functionBody(fbody));
>>>>        var f = Function.apply(this, parameters);
>>>>        f.__proto__ = proto;
>>>>        Object.defineProperties(f, props);
>>>>        return f;
>>>>      };
>>>>    })();
>>>> 
>>>> This is the same as Object.create except the second parameter is a
>>>> function.
>>>> 
>>>> It will create a new function whose function body is the same as the
>>>> function passed in.
>>>> 
>>>> I don't believe this is possible to do in ES5 without __proto__
>>> It is not indeed.
>>> This topic has been discussed a couple of times here. There is one
>>> proposal that is more generic than your solution which is the proto
>>> operator [1].
>>> 
>>> Basically, to create a function with a chosen prototype, you can do:
>>> -----
>>> var f = myProto <| function(a, b){return a+b;}
>>> Object.getPrototypeOf(f); // myProto
>>> f(1, 2); // 3
>>> -----
>>> 
>>> I'm a big fan of the proto operator proposal, however, as raised
>>> previously this operator relies on the object being created to have an
>>> intialisation syntax. This prevents, for instance, Date objects to have
>>> a custom prototype with this method. I am not very familiar with it yet,
>>> but I think that if they ever came to life, ParallelArrays [2] would
>>> suffer from the same problem.
>>> By the way, could someone add this concern as a note ("open issue" or
>>> "limitation" or something like this) in the proto operator page, please?
>>> 
>>> One even more generic way which would work even for objects that have no
>>> initialization syntax would to standardize one of [3] or [4]. Is there a
>>> wiki page mentionning these two functions somewhere? If not, may it be
>>> added and linked in some way to the proto operator?
>>> 
>>> David
>>> 
>>> [1] http://wiki.ecmascript.org/doku.php?id=harmony:proto_operator
>>> [2]
>>> https://github.com/RiverTrail/RiverTrail/blob/15ae7f6f77d9d2842d9d75458017efd9fe0fbee7/jslib/ParallelArray.js#L29
>>> [3] https://mail.mozilla.org/pipermail/es-discuss/2011-March/013141.html
>>> [4] https://mail.mozilla.org/pipermail/es-discuss/2011-March/013154.html
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>> 
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

--
Alex Russell
slightlyoff at google.com
slightlyoff at chromium.org
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723