name property for built-in functions??

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Wed Mar 11 03:31:59 PDT 2009


Garrett Smith wrote:
> I (finally) realized it would be useful to allow setting the name dynamically.
> 
> In a good number of cases, a closure is used where
> Function.prototype.bind() would be used. In this case, a
> generically-named or anonymous function is created and returned. It is
> not possible to parametrize the function name.
> 
> EventPublisher.fireEvent = function(publisher) {
> 
>   return function [publisher.eventName+"Handler"](ev) {
>     // code here.
>   };
> };
> 
> The square bracket is just pseudo. The syntax is incompatible.
> 
> Maciej' Function.create proposal:-
> 
> Function.create("[Foo bar]", "param1", "param2", "code(); goes(); here();");
> 
> - uses strings to create a function. Escaping strings in strings is
> awkward to read and write. Refactoring a function into strings to
> arguments to Function.create would be tedious and error-prone.
> Especiall if the soure already contains strings in strings (html = "<p
> id='p'>p<\/p>". Using with strings to build functions cumbersome.
> 
> Eval uses the calling context's scope. I do not know what the scope
> would be for a function created with Function.create.  To use the
> calling context's scope would seem to be not secure. However, it would
> seem necessary to wrap a function.
> 
> Possible alternative:-
>   Function.create( name, fun[, context] );

I don't see the problem here that would require overriding the context.
The scope used by fun would be its original lexical scope. In the example
above:

  EventPublisher.fireEvent = function(publisher) {
    return Function.create(publisher.eventName + "Handler", function(ev) {
      // code here
      // can refer to 'publisher', etc. if needed
    });
  };

All the hypothetical Function.create does is to create a new function that
behaves the same as its fun argument, but with a different name. The
.name property of all function objects would be non-[[Writable]] and
non-[[Configurable]].

Whether this is actually needed, I'm not sure, but it has all of the
functional and security properties I've seen stated as desirable so far
in this thread.

-- 
David-Sarah Hopwood ⚥



More information about the Es-discuss mailing list