simple variables as properties?

[Jorge]

Incidentally, there are plans to change the way - this - behaves in ES
3.1 (the next planned spec version, as ES 4 is on the backburner
again) such that - this - may actually be null or undefined in some
circumstances.

Yes. 'this' shouldn't point to the global object unless f() ===
window.f(), isn't it ?
And 'this' for inner functions should probably better point to the
'outer' 'this'...

What other 'circumstances' are being devised ?

 

[Thomas 'PointedEars' Lahn]

I can't figure out another case in which a call to f() would preset
'this' to something !== window ?

I do not know what you can figure out.

However, the (strict) equals operation is pointless as we are dealing with a
host object here. Therefore, you cannot reliably determine whether it is,
or is not, the same object. Not this way or any other way. Some want to
believe that there is proof they are the same, though.

Could you show me how, when ?

(Not using 'with', .call() nor .apply())

You missed the point, again.

Let's say that f= object.method= function () { ... }

Called as an object's method : object.method()
Called as a function : f()

However, that is merely your amateurish interpretation, not what actually
happens. Which I am getting tired pointing out to you. Read the Spec.


PointedEars

 

[Lasse Reichstein Nielsen]

Jorge wrote:

Incorrect, because a function is *always* called as an object's method,
even though identifier resolution has to work along the scope chain, and
may only find a property with that name as one of the Global *Object*.

That's one view, but no more correct than the opposing one: that the
"this" operator always evaluates to a value in a function code's
execution context, even when the function is *not* called as a method.

The closest the specification comes to defining "a method" is:
"A function stored in a property of an object is called a method."
(§ 4.3.3).

In the example:
function f(){return this;}
alert(f());
the function "f" is never a method according to this definition,
so it isn't called as a method.

There is no doubt what happens when you call a function. All we can
argue about is what to call it.
/L

 

[Thomas 'PointedEars' Lahn]

That's one view, but no more correct than the opposing one: that the
"this" operator always evaluates to a value in a function code's
execution context, even when the function is *not* called as a method.

Again, a function is always a method (there may be one exception: an
anonymous function immediately called after evaluation of its function
expression). Therefore, there is no case when it is not called as a method.

The closest the specification comes to defining "a method" is:
"A function stored in a property of an object is called a method."
(§ 4.3.3).
Exactly.

In the example:
function f(){return this;}
alert(f());
the function "f" is never a method according to this definition,
so it isn't called as a method.

You are mistaken. `f' is a property of the Variable Object of the execution
context; an object inaccessible by code when it is function code, but an
object nevertheless. That object is in the scope chain.

There is no doubt what happens when you call a function. All we can
argue about is what to call it.

*g*


PointedEars

 

[Jorge]

I do not know what you can figure out.

Nor the answer to the question. (?)

However, the (strict) equals operation is pointless as we are dealing with a
host object here.

This has nothing to do with what we're talking about.

(more verborrea)
idem.



You missed the point, again.

You duck and run away ?

However, that is merely your amateurish interpretation

That's not an interpretation. It's all you need to 'learn' in order to
apply the rule.

not what actually happens.  Which I am getting tired pointing out to you.

I'm always glad to learn when I'm wrong, so, having learned what you
need to in order to apply the rule, why don't you (instead of posting
much more -even unrelated- verborrea) just prove with an example where
else the rule fails (as Richard did wisely pointing out that it may
fail within a 'with', for those who use 'with') ?

Thanks,

 

[Jorge]

I do not know what you can figure out.

Nor the answer to the question. (?)

However, the (strict) equals operation is pointless as we are dealing with a
host object here.

This has nothing to do with what we're talking about.

(more verborrea)
idem.



You missed the point, again.

You duck and run away ?

However, that is merely your amateurish interpretation

That's not an interpretation. It's all you need to 'learn' in order to
apply the rule.

not what actually happens. Which I am getting tired pointing out to you.

I'm always glad to learn when I'm wrong, so, having learned what you
need to in order to apply the rule, why don't you (instead of posting
much more -even unrelated- verborrea) just prove with an example where
else the rule fails (as Richard did wisely pointing out that it may
fail within a 'with', for those who use 'with') ?

Thanks,

 

[Henry]

On Sep 8, 1:04 pm, Thomas 'PointedEars' Lahn wrote:

I can't figure out another case in which a call to f()
would preset 'this' to something !== window ?

Could you show me how, when ?

(Not using 'with', .call() nor .apply())

<snip>

Disregarding quibbling about whether - window - is equivalent to the
ECMAScript global object (and there is plenty of room for quibbling in
that direction), the specification allows another situation in which a
non-property accessor to the left of call operators may allow a - this
- that was not the global object. Host functions/object methods are
explicitly allowed to return a Reference type if they want to. In the
even that a host function did return a Reference type that had a non-
activation object as its - base - and its property name referred to a
function reference value, and the call operators were directly applied
to the value returned from the call then in that second function call
the - this - keyword would refer the - base - of the Reference type
(assuming it was no an Activation object).

I am not aware of a single host method/function that behaves in this
way, but that does not mean that they do not exist, and the
specification allows for the possibility of their existence.

The form of this construct (if it exists) would be:-

HostObject.methodName()();

- where the first set of parenthesise call the method and the second
set call the return value from the first function call, which is
allowed to be a Reference type for host functions/methods.

IE host objects support this form of usage. If, for example, you had a
number of forms each with a field named 'f' IE will happily execute:-

document.forms(0)('f');

- and the call to the return value from the - docuemnt.forms(0) -
knows which of the forms it is associated with, such that the
subsequent ('f') returns the reference to the field in the correct
form. This could be achieved by - docuemnt.forms(0) - returning a
Reference type, but in practice it is not (other manipulations of the
construct can be used to demonstrate that returning a Reference type
is not what is happening here).

 

[Lasse Reichstein Nielsen]

....[example that didn't fly]...

You are mistaken. `f' is a property of the Variable Object of the execution
context; an object inaccessible by code when it is function code, but an
object nevertheless. That object is in the scope chain.

Ok, I accept that.
But then:
var x = (function(){ return this; })();
is calling a function that isn't a property of any object, i.e., isn't
"called as a method" in any sense.

/L

 

[Thomas 'PointedEars' Lahn]

...[example that didn't fly]...

You are mistaken. `f' is a property of the Variable Object of the execution
context; an object inaccessible by code when it is function code, but an
object nevertheless. That object is in the scope chain.

Ok, I accept that.
But then:
var x = (function(){ return this; })();
is calling a function that isn't a property of any object, i.e., isn't
"called as a method" in any sense.

First, that is *not* what Jorge was using to explain his meaning.

Second, you are pretty much preaching to the choir:

,-<[email protected]>
|
| Again, a function is always a method (there may be one exception: an
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| anonymous function immediately called after evaluation of its function
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| expression). Therefore, there is no case when it is not called as a
^^^^^^^^^^^
| method.


PointedEars