On May 16, 2011, at 1:36 PM, Axel Rauschmayer wrote:
> Thanks for explaining the details. With "temporary result", I meant what you
> call "object reference". Similar to Common Lisp places (setf etc.), I
> suppose. If you use the conditional operator, you can force the dereferencing
> of an obj
> This breaks the web, so regardless of whether it's worth it, it's just not
> possible. Harmony and non-Harmony share a heap with the same built-in
> globals. If you change Function.prototype.call and Function.prototype.apply,
> you break the web.
I suspect that a new type for the new-style fu
d) At runtime, a function invoked as a non-method gets a dynamic
ReferenceError if it tries to refer to |this|. This would just be kind of
obnoxious, I think, since if the function wants to test whether it's been
called as a non-method it has to do something like
let nonMethod = false;
t
> - "self" is just another parameter, it can be called anything.
> - Function.prototype.call() and Function.prototype.apply() would have one
> parameter less.
> - IIRC, this is more or less how Python works.
> - Probably not worth it, migration-cost-wise.
This breaks the web, so regardless of whe
Yeah, sorry, I was wrong about the need for two constructs.
Example code:
> var obj = {
> id: "ac3fb",
> method: function(self, msgs) {
> msgs.forEach(function(msg) {
> console.log(self.id+": "+msg);
> });
> }
> };
>
> // Invoke as method
> obj.method([ "h
On Mon, May 16, 2011 at 10:15 AM, David Herman wrote:
>
> d) At runtime, a function invoked as a non-method gets a dynamic
> ReferenceError if it tries to refer to |this|. This would just be kind of
> obnoxious, I think, since if the function wants to test whether it's been
> called as a non-me
>> How do you define "non-method"?
>
> A function that is not invoked as method. Right now, the same kind of
> construct is used for both true functions and methods. I’m proposing a new
> construct (similar to the distinction that Python makes): a function that
> does not have an implicit |this
>>> Oh, I see. But there's still a problem. Without a class or similar
>>> declarative form to associate the method with an object or class of
>>> objects, making the function syntax reject or accept |this| in the function
>>> body is not enough. A method needs to be enclosed by a class.
>>>
>>
On May 15, 2011, at 2:36 PM, Axel Rauschmayer wrote:
> Caveat: I am aware that what I’m suggesting might clash too hardly with
> current semantics (how to handle invocation, apply(), call(), etc.), but I am
> interested in the arguments against it.
The strawman contains bits of rationale, pleas
Caveat: I am aware that what I’m suggesting might clash too hardly with current
semantics (how to handle invocation, apply(), call(), etc.), but I am
interested in the arguments against it.
>> (1) I would prefer non-method functions not to have a binding for |this| at
>> all.
>
> How do you de
On May 15, 2011, at 1:09 PM, Axel Rauschmayer wrote:
> Sorry for bringing this up again, but I don’t think this particular question
> has been answered yet:
>
> (1) I would prefer non-method functions not to have a binding for |this| at
> all.
How do you define "non-method"?
It would make an
Sorry for bringing this up again, but I don’t think this particular question
has been answered yet:
(1) I would prefer non-method functions not to have a binding for |this| at all.
(2) The solution for ES.next seems to be to (e.g. internally, via =>) bind to
|this| of the surrounding method.
I
12 matches
Mail list logo
