OO javascript... this doesn't appear to point to the object

V

VK

Michael said:
Exactly equivalent? No, certainly not. However, in most ways that
matter, they are the same.

"ways that matter" is a dangerous term: it may cover too many things in
too ambiguous way (say OOP or not OOP, inheritance emulation or native
inheritance: these issues can be dismissed by this term as well
occasionally).

function f() {}
and
var f = function(){};

have the same internal difference as:
var f = new Function;
and
var a = new Function;
var f = a;

(I am talking about referencing and memory representation, not about
FunctionStatement vs FunctionExpression differences).

Is this matter or not? It depends on circumstances. At the very least
an universal finalizing "it is not matter" is not applicable here.
You have that backwards.

Yep. I wanted to follow-up correction right away, but decided to give
the pleasure of correction to experts. :)

How is that useful or helpful to anyone? What pertinent information do
you even think it shows? As far as I can see, all it demonstrates is the
choices that Microsoft Script Debugger makes when referring to functions.

<http://www.geocities.com/schools_ring/blogs/Image1FF.gif>
shows the stack state for var something = function(){}

<http://www.geocities.com/schools_ring/blogs/Image2FF.gif>
shows the stack state for function something(){}

If you insist, I can use a full-scaled C++ spy so we would count "one
against two" on a big UA-independed picture. But it will most probably
make me all upset and grunchy afterwards (as any person vasted his time
on useless experiment). :) :-|


Whether they look silly or depends upon how they use the latter.

Thinking back I see some sense in using
var f = function f(){} // both identifiers are the same

That allows to normalize function toString results and to use function
name instead if arguments.callee. Still a bit weird looking but at
least it may have some sense.
 
J

John G Harris

VK said:
"Ownership" is not a programming category at all. I used this term from
your post poetically and I put it into quotes at the end ("transferred
meaning" quotes).

It was *your* article that first talked about owning.

But you are right pointing to an omission:
"No one: until this function is called. And then it's owned by the
calling object instance <ins>during the call</ins>." - that will be
better.

You've still got it wrong!!!!!!!!!!!

It's not owned, and it's not the "calling object instance".

You've been learning from wrong prof's :)

I've got a pdf copy of the C++ ISO Standard. Neither OID nor Object
Identifier appear anywhere in the Standard. They are nothing to do with
the C++ language.

OID's are the basic for class-based languages - once again - in the
internal mechanics.

I suspect you've been reading about .NET. Perhaps Microsoft have put
things called OIDs into their .NET implementation, but other people
haven't.

But we can stay on the level of the language itself by saying that
JavaScript doesn't implement encapsulation unlike C++ or say Java do.

Javascript implements encapsulation, but some details are different from
C++ and Java, just as C++ and Java differ in some details.

John
 
V

VK

John said:
It was *your* article that first talked about owning.

"Object instance owning the called method " -
yep, my bad, the same omission
Object instance currently "owning" the called method

the word "currently" and quotes would possibly prevent this branch -
but should we regret about it?
You've still got it wrong!!!!!!!!!!!

It's not owned, and it's not the "calling object instance".

that's getting too far from programming into free arts aspects (styles
of speech etc.) Which verb do you want? using? executing? grabbing?
putting hands on? as by ECMAScript lingo it is using "internal [[Call]]
property" then "calling" would be the most appropriate IMHO. Or it is
not an object instance? or object but not an instance (just Object)? or
an instance but not an object (just "stuff")? :)
I've got a pdf copy of the C++ ISO Standard. Neither OID nor Object
Identifier appear anywhere in the Standard.

Of course they don't. Same way scavengers, garbage collector and memory
heaps do not normally appear in JavaScript specifications. Why do you
think I used the word "internally"? Externally (for the language) it is
called encapsulation. But encapsulation is not a natural phenomenon
falled into C++ by His will :) It is just another abstraction - and
oid stamping is how this abstraction is internally ticking.
Javascript implements encapsulation, but some details are different from
C++ and Java, just as C++ and Java differ in some details.

Some small sample maybe?
 
M

Michael Winter

VK said:
"ways that matter" is a dangerous term: it may cover too many things
in too ambiguous way ...

Except it doesn't here. I provided (what I believe to be, anyway) a very
clear explanation in my previous post.

[snip]
function f() {}
and
var f = function(){};

have the same internal difference as:
var f = new Function;
and
var a = new Function;
var f = a;

So none, then? In all four cases, there's a function object referenced
by a variable, f. In the latter case, there's an extra reference, a, but
that changes nothing about the function object itself.

The most significant, potential difference between the two pairs is that
function objects created via the Function constructor function may only
ever have the global object in their scope chain.

[snip]
<http://www.geocities.com/schools_ring/blogs/Image1FF.gif> shows the
stack state for var something = function(){}

<http://www.geocities.com/schools_ring/blogs/Image2FF.gif> shows the
stack state for function something(){}

That doesn't answer either of my questions. In fact, it provides even
less information than before.

That Microsoft Script Debugger uses the identifier in a function
declaration to refer to that function means absolutely nothing, except
perhaps the implication that JScript keeps such information around. You
presented it before as a supposed means of education, yet I fail to see
what relevance it has to anything. What is it supposed to teach me or
anyone else? How does it help someone understand how functions behave,
or the behavioural differences between function expressions and
declarations? My suspicion is that it's just an irrelevance.
If you insist, I can use a full-scaled C++ spy so we would count "one
against two" on a big UA-independed picture. ...

Why? That still wouldn't answer my questions.

[snip]
Thinking back I see some sense in using
var f = function f(){} // both identifiers are the same

That allows to normalize function toString results and to use
function name instead if arguments.callee. Still a bit weird looking
but at least it may have some sense.

A better, albeit artificial, example would be:

(function outer() {
function inner() {
/* ... */
}
})();

The arguments.callee property is one means of referencing a function
object created via a function expression within the function itself, but
in the example above, that wouldn't help at all if code within the body
of the inner function needed to reference the enclosing function; there,
the callee property would reference the inner function. The identifier,
outer, can provide that reference. It can also be used instead of the
callee property (where that would be suitable) as a more meaningful way
of accessing the function object for recursion.

Mike
 
J

John G Harris

VK said:
John G Harris wrote:
You've still got it wrong!!!!!!!!!!!

It's not owned, and it's not the "calling object instance".

that's getting too far from programming into free arts aspects (styles
of speech etc.) Which verb do you want? using? executing? grabbing?
putting hands on? as by ECMAScript lingo it is using "internal [[Call]]
property" then "calling" would be the most appropriate IMHO. Or it is
not an object instance? or object but not an instance (just Object)? or
an instance but not an object (just "stuff")? :)

It's code that calls functions. Objects cannot call anything. Therefore
"calling object" has no meaning. You must not use "calling object" in
your personal description of one of the 'this' cases because it would be
meaningless.

Another problem is that there are up to three objects involved in a
function call. You haven't said which object you're talking about.

Incidentally, "object" and "instance" mean the same thing. "object
instance" is redundant, but harmless.

Of course they don't. Same way scavengers, garbage collector and memory
heaps do not normally appear in JavaScript specifications. Why do you
think I used the word "internally"? Externally (for the language) it is
called encapsulation. But encapsulation is not a natural phenomenon
falled into C++ by His will :) It is just another abstraction - and
oid stamping is how this abstraction is internally ticking.
<snip>

What do you think an OID is? What do you think OID stamping is?

Whatever they are, the majority of C++ programs don't have them.

John
 
V

VK

The most significant, potential difference between the two pairs is that
function objects created via the Function constructor function may only
ever have the global object in their scope chain.

You probably mean "may only have Global object as current object" (what
[this] points to). That is true except overloaded calls like
FunctionObject.call(context) and FunctionObject.apply(context, args)

A nitpick, I know - but can I do it once? :)

For the default object the context can be set to anything by say
new Function('arg1', 'arg2', "with(ObjName){...}");
That is really special in function instances created over new
Function() is that body argument is casted to string first and then
re-evaluated on each call. That is the reason you cannot store directly
current [this] value in new Function.
What is it supposed to teach me or
anyone else? How does it help someone understand how functions behave,
or the behavioural differences between function expressions and
declarations? My suspicion is that it's just an irrelevance.

As I said before, I wanted to mention that

function f(){}
obj.method = f;

and

obj.method = function(){}

do not differ anyhow in the "degree of ownership" between obj and its
method.
 
R

Richard Cornford

VK wrote:

Failing to attribute your quotes again?
The most significant, potential difference between the two
pairs is that function objects created via the Function
constructor function may only ever have the global object
in their scope chain.

You probably mean "may only have Global object as current
object" (what [this] points to).

That is extremely unlikely as Mike knows what he is talking about and so
would not make a false statement, and certainly not using one using such
vague terminology.

As a function created with the Function constructor can be used in the
same way as any other function object, and so assigned to properties of
objects, properties of constructor's prototypes, event handling
attributes and so on, the - this - keyword used within such a function
can refer to all sorts of objects.
That is true except overloaded calls like
FunctionObject.call(context) and
FunctionObject.apply(context, args)

No, what you have just written is just false.
A nitpick, I know - but can I do it once? :)

You can nit-pick, but you look a fool in the attempt because you don't
know what you are talking about.
For the default object the context can be set to anything
by say new Function('arg1', 'arg2', "with(ObjName){...}");

That will still not put any object other than the global object onto the
function's scope chain, only onto the scope chain of the execution
context used when the function is executed.
That is really special in function instances created over
new Function() is that body argument is casted to string
first and then re-evaluated on each call.

It is hardly unusual for javascript's native functions/constructors to
type-convert their arguments into a required type. It is also not
particularly "special", in the sense of needing any attention being drawn
to, as you would be hard pressed to find any documentation that suggested
using anything but a string as the function body argument.
That is the reason you cannot store
directly current [this] value in new Function.

That does not make sense. What is "store directly current [this] value in
new Function" supposed to mean? In what sense can you "store" any value,
let alone a - this - value, "in" any function (beyond assigning values as
named properties of function objects)?

Are you making a confused stab at referring to specific object instances
through the scope chain of function objects? The ability to do that in a
function object resulting form a function expression/declaration and not
in a function created with the function constructor has nothing to do
with the constructor taking string arguments, it is because " function
objects created via the Function constructor function may only ever have
the global object in their scope chain".
As I said before, I wanted to mention that

You never actually answer the questions you are asked, do you. You where
asked to explain what you expected to be learnt from all the URLs you
posted.

That you can never answer these questions makes it very obvious that you
don't know what you are talking about. You may try to hide behind
misdirection to the irrelevant, but you are fooling nobody but yourself.
function f(){}
obj.method = f;

and

obj.method = function(){}

do not differ anyhow in the "degree of ownership" between
obj and its method.

You mean that in a language where there is no "ownership" the degree of
absence of ownership is not influenced by how code is written? A rather
pointless thing to be trying to point out, especially as the only person
likely to imply any notions of "ownership" is you.

Richard.
 
M

Michael Winter

Richard said:
VK wrote:

Failing to attribute your quotes again? [MLW:]
The most significant, potential difference between the two pairs
is that function objects created via the Function constructor
function may only ever have the global object in their scope
chain.

You probably mean "may only have Global object as current object"
(what [this] points to).

That is extremely unlikely as Mike knows what he is talking about and
so would not make a false statement, and certainly not using one
using such vague terminology.

As much as I appreciate the vote of confidence, I wouldn't put it past
myself. I can only hope that the amount of any lingering ignorance and
the frequency of mistakes on my part would decrease over time.

That said, the particular issue above is hard to get wrong: it's easily
demonstrated, and spelt out quite clearly in step 16, section 15.3.2.1,
ECMA-262 (3rd Ed.)

[snip]

Mike
 
M

Michael Winter

VK said:
The most significant, potential difference between the two pairs is
that function objects created via the Function constructor function
may only ever have the global object in their scope chain.

You probably mean "may only have Global object as current object"
(what [this] points to). ...

No, I meant what I wrote. The value of the this operator is determined
in same way for function objects no matter how they are created.

[snip]
For the default object the context can be set to anything by say
new Function('arg1', 'arg2', "with(ObjName){...}");

That doesn't change the scope chain of the function object. A with
statement adds the referenced object to the top of the scope chain only
when evaluated and will only affect the code within its own block.
That is really special in function instances created over new
Function() is that body argument is casted to string first and then
re-evaluated on each call.

I'm sorry, what? The arguments to the Function constructor are evaluated
once and the resulting function is constant in its definition. The only
reason to re-evaluate those arguments is if the NewExpression itself is
re-evaluated. That is, if a new function object is created.
That is the reason you cannot store directly current [this] value in
new Function.

What's that supposed to mean?

[snip]

Mike
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top