Can I know if "new Func()" or "Func()" is called?

[Michael Winter]

Matt Kruse wrote:
[snip]

The breadth of your ignorance is astounding.

After humbly suggesting to go f*** yourself, Sir ...

You would do Usenet at large a favour if you took your own advice.

(and start learning JavaScript instead of ECMAScript):

Still living in a private world where JavaScript isn't an implementation
of ECMAScript, eh?

I gave an answer to OP question,

And, as usual, it was a bad one. The constructor isn't "running in the
scope of the newly created object", and whether a function is "top
level" or not is irrelevant with regard to which object is referenced by
the this operator.

and later went on a straw-man trick so I called "current object" as
"default object".

Both are meaningless, anyway.

That is maybe a huge crime by your scale:

The incorrect use of terminology is not a huge crime, no, but unless it
was by accident, knowledge and understanding wouldn't permit such a mistake.

but by my scale it has no comparison to the amount of b.s. posted in
this thread by other people in relevance to function constructors.

Other people? LMFAO!

The statement alone that "returning null from a constructor has no
effect" demostrates such shiny lack of a real javascript programming
experience ...

Really? So what do you expect:

function MyObject() {
this.member = 'value';

return null;
}

var object = new MyObject();

to do? Return null? Raise an exception? Return an object but omit the
property? Shame it doesn't do any of those things: it returns the object
as if the return statement wasn't even there. Even if you only tested in
Fx or IE, you would have found that out for yourself.

Will you ever learn?

Mike

 

[Richard Cornford]

good and simple.

But still not reliable:-

var obj1 = new TestConstructor();

var obj2 = TestConstructor.call(obj1); // <- no - new - operator.

will alert "New Object" twice, when the second call is not as a
constructor. Also:-

var obj1 = new TestConstructor();

obj1.method = TestConstructor;

var obj2 = obj1.method();

- again will alert "New Object" twice when the second call to -
TestConstructor - is as a method not a constructor.

The odds are good that the actual problem that the OP is attempting to
address does not really require a reliable solution, but as we have seen
there are numerous possibilities, of more or less complexity and with
differing reliabilities and compatibilities. Until the OP answers the
question 'why?' knowing which would best address the issue is not
possible.

Richard.

 

[Jeremy]

But still not reliable:-

var obj1 = new TestConstructor();

var obj2 = TestConstructor.call(obj1); // <- no - new - operator.

will alert "New Object" twice, when the second call is not as a
constructor. Also:-

var obj1 = new TestConstructor();

obj1.method = TestConstructor;

var obj2 = obj1.method();

- again will alert "New Object" twice when the second call to -
TestConstructor - is as a method not a constructor.

The odds are good that the actual problem that the OP is attempting to
address does not really require a reliable solution, but as we have seen
there are numerous possibilities, of more or less complexity and with
differing reliabilities and compatibilities. Until the OP answers the
question 'why?' knowing which would best address the issue is not
possible.

Richard.

Interesting. Can't think of a way to fix those scenarios without adding
extraneous properties to the object, so I guess you're right.

I also have never had to use function.call() in my entire life, and I
can't see any reason why you would want to attach a constructor as a
method to another object.

Then, I can't really see why it would ever be desirable to call a
constructor as a regular function. Seems like asking for trouble, IMHO.
I agree that the OP should explicate his or her reasoning.

If you have functionality that you want to use both in the constructor
and as a normal function, why not remove that functionality and
encapsulate it in a separate function apart from the constructor?

Jeremy

 

[VK]

You would do Usenet at large a favour if you took your own advice.

I'm mostly very respectful to the netiquette, and I definitely do not
attack anyone just out of sport. But over the last year and half I'm
getting a bit fed up by very few but highly noisy people in c.l.j. That
must be an age change or a work stress, but I'm getting no more
strength to smile on it. So you are getting the same advise I just gave
to another person (avoiding to retype, just scroll up). You don't want
such advises in the future (fully typed is such case) - then avoid
comments on putting me down.

Still living in a private world where JavaScript isn't an implementation
of ECMAScript, eh?

Still living in a private world where JavaScript == ECMAScript, Global
== window, only one Global per document, eh?
(just your wording back)

function MyObject() {
this.member = 'value';

return null;
}

var object = new MyObject();

to do? Return null? Raise an exception? Return an object but omit the
property? Shame it doesn't do any of those things: it returns the object
as if the return statement wasn't even there. Even if you only tested in
Fx or IE, you would have found that out for yourself.

Will you ever learn?

We are all learning - all our life. The danger is to decide one day
that you have nothing more to learn as you know everything you have to
know. That is really bad. The rest is always fixable.

Yes, it has to be a reference to an object used in the return
statement. Primitives are ignored. I was wrong with this one. That's a
drawback of my knowledge I guess: I don't give a damn of how something
is called or ticking until I need to know this to get my money. As I
never had to make a "constructor" constructing nothing, I did not look
that does return null do in the constructor call context. The singleton
I posted was used for years w/o any problems because you can return
other object reference instead of the newly created instance reference:

<script type="text/javascript">
var foo = new Object();

function AnObject(){
this.foo = 'bar';
return foo;
}

var obj = new AnObject();

alert(obj.foo); // undefined
</script>

- but of course you already knew it.

 

[VK]

I just hate these Books of ECMA liturgies,

And look where that gets you.

And where *that* gets you (see a bit further)

The primary false statement under discussion here has been your
assertion that in a constructor the newly created object is added to
the scope chain.

I had a stupid (from my side) attempt to write something using your
regular ECMAScript lingo (scope chain, Activation etc.) and I did a
mistake. There are *current object* (pointed by [this]) and *default
object* (used say within with(){} construct). (If anyone doesn't like
these terms then she can go to hell - or to any descent
JavaScript/JScript reference).
So now I will not mix these terms and I know to avoid speaking
Ecmaspeak anymore. A valuable lesson.

There is no such thing as an "empty instance of MyObject", beyond there
being a native ECMAScritp obejct with its internal [[Prototype]]
property referring to the value of - myOjbect.prototype - at the time.

Again: what language are you talking about? JavaScript? Java? C++? C#?
VB? They all have "only one object type" in your terms. An Object
instance and say Applet instance in JVM are not marker by different
colors they are not "one is squared and other is rounded". They are
not, trust me. The same structure with different set of properties and
references to other objects.

import java.applet.*;
import java.awt.*;

public class test extends Applet {
String demo;

public void init() {
demo = (this instanceof Object) ? "true" : "false";
}

public void paint(Graphics g) {
g.drawString(demo, 20, 20);
// will be "true" of course, I did not test it,
// but feel free to make an applet to see it
}
}

So Java is a single object type language? Just fine...

The Object object is contained in all other objects; all of its methods
and properties are available in all other objects. Every object "first
born" as a naked empty generic Object instance and it becomes something
different during the instantiation process. Yet every object remembers
its "babyhood": so besides of being an instanceof its class it also an
instanceof Object.

Trying to not be nasty (or pretending of trying not to - it seems
to me that javascript is the only language you know - but you know it
very well. I noticed it before that you have a tendency to declare some
generic OOP things as javascript-specific. I have another problem
though: I know and I have to use too many programming languages, so
sometimes they clinch in my head.

The - null - value is not an object in javascript so a - return null; -
statement in a function that is called as a constructor will not result
in a null value. Try it:-

function AnObject(){
return null;
}
AnObject.prototype.testValue = 'XXX';

var obj = new AnObject();

alert(obj.testValue);

- which alerts 'XXX' rather than erroring, which is what it would do if
the - new AnObject() - expression returned null.

Silly me.
I was wrong with this one. That's a drawback of my knowledge I guess: I
don't give a damn of how something is called or ticking until I need to
know this to get my money. As I never had to make a "constructor"
constructing nothing, I did not look that does return null do in the
constructor call context. The singleton I posted was used for years w/o
any problems because you can return other object reference instead of
the newly created instance reference: but return [some primitive] is
silently ignored.

 

[Richard Cornford]

And where *that* gets you (see a bit further)

I am quite happy with the position I am in now.

I had a stupid (from my side) attempt to write something
using your regular ECMAScript lingo

You man the technical terminology from the language specification? That
is the terminology which is sufficiently well defined that anyone can
read the specification and know with absolute certainly what is meant,
and so understand anyone else using that terminology (correctly) to talk
about the language.

(scope chain, Activation etc.) and I did a
mistake.

Of course you did. To use technical terminology in a technical newsgroup
you have to understand what it means (or at least be interested in
learning what it means). Without understanding it using the terminology
just degrades it into nonsense jargon used as a smokescreen to disguise
ignorance and misconceptions. And that smokescreen is not going to be
very effective if attempted in a context where others actually do
understand the terminology. That is, you can impress people who don't
know any better but the people with the technical understanding can see
right through you.

However, your previous habit of making up your own 'technical' jargon is
really worse as it turns what you say into a sort of nonsense that cannot
even be corrected, as it has no real meaning for anyone else.
Unfortunately for the newcomers and novices who read this group 'nonsense
jargon' pretty much characterises your posts. Making it more difficult
for them to properly comprehend the concepts and terminology that really
does apply to javascript.

There are *current object* (pointed by [this]) and
*default object* (used say within with(){} construct).
Nonsense.

(If anyone doesn't like these terms then she can go to
hell -

That is a poor attitude, as anyone taking these terms seriously will
understand javascript worse than in they had heard them at all. You may
not be able to perceive it but you are doing harm when you talk this
nonsense on this newsgroup.

or to any descent JavaScript/JScript reference).
So now I will not mix these terms and I know to
avoid speaking Ecmaspeak anymore. A valuable lesson.

So you will only be using your made up (or inappropriately borrowed)
jargon form now on?

There is no such thing as an "empty instance of MyObject",
beyond there being a native ECMAScritp obejct with its
internal [[Prototype]] property referring to the value of -
myOjbect.prototype - at the time.

Again: what language are you talking about?

Javascript. How many other languages would have instances of the native
ECMAScript object?

JavaScript? Java? C++? C#? VB? They all have "only one
object type" in your terms.

Strongly type languages have a very definite notion of objects being of
different types. And the compiled languages almost certainly carry those
distinctions into creating distinct structures in memory to represent
those objects.

An Object instance and say Applet instance in JVM are not
marker by different colors they are not "one is squared
and other is rounded". They are not,

You point is?

trust me.

I trust you not to know what you are talking about here either.

The same structure with different set of properties and
references to other objects.

import java.applet.*;
import java.awt.*;

public class test extends Applet {
String demo;

public void init() {
demo = (this instanceof Object) ? "true" : "false";
}

public void paint(Graphics g) {
g.drawString(demo, 20, 20);
// will be "true" of course, I did not test it,
// but feel free to make an applet to see it
}
}

So Java is a single object type language? Just fine...

All Java objects are subclasses of the Java Object class (and as you
mentioned C++, that is not true in C++ ). The point of a subclass is that
it is a different type than its super-class. And the relationship is very
certain; you can cast a sub-class into its superclasses, but you cannot
cast a superclass instance into one of its subclasses.

In javascript, where there are no classes, and there is only one object
type no such restriction exists. What you call an "instance of MyObject"
is sufficiently flexible to be transferred into an instance of what is
conceptually a superclass of MyObject, and you can do that in javascript
precisely because all the objects are just instances of the native
ECMAScript object and so all of preciously the same type.

The Object object is contained in all other objects;
all of its methods and properties are available in
all other objects.

That is not true in javascript. Because the inheritance if through the
prototype chain it is entirely possible for a instance of the native
ECMAScript object to, for example, mask a method of the -
Object.prototype - object with a non-callable value. Effectively
rendering the method unavailable and unusable. You just cannot do that in
Java; Java objects can only overload the methods they inherit from the
Object base class with methods with the same signature.

Every object "first born" as a naked empty generic Object
instance and it becomes something different during the
instantiation process.

Where, and based upon what? C++ has no Object base class. Java objects
almost certainly come into existence as specific memory structures that
do no more, and no less, than accommodate objects of that one type
(because their type cannot be modified post instantiation and anything
else would waste resources).

Yet every object remembers its "babyhood": so besides of
being an instanceof its class it also an instanceof Object.

You do realise that the - instanceof - operator has very different
behaviour between Java and javascript? Attempting to draw comparisons
between the two languages based upon the results of uses of -
instanceof - is more likely to be misleading than anything else.

Trying to not be nasty

That's alright, the contempt I feel for you would negate the attempt if
made.

(or pretending of trying not to - it seems
to me that javascript is the only language you know

Your perceptions are rarely accurate.

- but you know it very well.

If you really think I know javascript very well why do you argue when I
tell you that you are wrong, and if you are going to argue why don't you
test your case so you don't find yourself trying to defend an untenable
position?

I noticed it before that you have a tendency to declare
some generic OOP things as javascript-specific.

I have noticed in the past that what you say in connection with OOP
contains as many misconceptions as what you say when talking about
javascript.

I have another problem though: I know

Or, you think you 'know'. You behave as if you know something about
javascript, yet the evidence is that you know less than nothing about it.

and I have to use too many programming languages,

"Use" may be overstating what you do.

so sometimes they clinch in my head.

The contents of your head do seem very mixed-up.

Silly me.
I was wrong with this one.

So you were wrong about the constructed object being added to the scope
chain, wrong about the constructed object being an "instance of MyObject"
and wrong about the behaviour of return statements in constructors. So
what exactly were you right about.

Look at how much time you have wasted by making the mistake of thinking
that you know what you are talking about when you have repeatedly been
told hat you do not.

That's a drawback of my knowledge I guess:

Mistaking what you have for "knowledge" is your main mistake.

I don't give a damn of how something is called or ticking
until I need to know this to get my money.

Yet you re willing to tell other people what is happening, and then
object to being corrected on the rare occasions when what you write is
sufficiently coherent to be corrected.

As I never had to make a "constructor" constructing nothing,
I did not look that does return null do in the constructor
call context.

Yet you frequently use - return null; - statements in functions that are
clearly intended to be used as constructors (and that error has been
pointed out to you in the past), and post examples of such code to this
group.

Think about that for a moment. You are writing code that you freely admit
you did not understand. You were putting such stamens into code
(presumably including code that you have been paid for) without knowing
what that code would actually do. That is not competent programming, it
is programming by coincidence and by mystical incantation.

The singleton I posted was used for years w/o any problems
because you can return other object reference instead of
the newly created instance reference: but return
[some primitive] is silently ignored.

Using 'it has worked for me for years' as your only justification for
writing particular lines of code is pretty much the definition of
"programming by coincidence".

You would not last five minutes in any of the software houses that I have
worked for (indeed you would not get through their doors in most cases).
It is amazing that you have got away with your incompetence for as long
as you claim you have (but then if you are as insane as you come across
you employment record may just be another of your fictions). I can
certainly understand your desire to remain anonymous. I would be deeply
ashamed of taking money of people for the code you write.

Richard.

 

[Richard Cornford]

Interesting. Can't think of a way to fix those scenarios
without adding extraneous properties to the object, so
I guess you're right.

There is every possibility that they don't kneed fixing in the actual
context of application.

I also have never had to use function.call() in my entire
life, and I can't see any reason why you would want to attach
a constructor as a method to another object.

Then, I can't really see why it would ever be desirable to
call a constructor as a regular function. Seems like asking
for trouble, IMHO. I agree that the OP should explicate
his or her reasoning.

Absolutely. "Solutions" proposed in ignorance of the real problem that
they are intended to solve are unlikely to be truly successful, though
they may give that impression to anyone who needed to ask for help with a
solution in the first place.

If you have functionality that you want to use both in the
constructor and as a normal function, why not remove that
functionality and encapsulate it in a separate function
apart from the constructor?

Yes, I would consider that a very questionable design, but it is not
necessarily the issue in question here. There are, for example, people
trying to create 'library' code that is intend to be used by the most
unskilled developers, who want to second guess and error-correct for
those unskilled programmers. If that is the issue here then those
incompetent library end users may well do things as strange as using
the - call - method on a constructor, or making it into a method of an
object. In which case a very robust approach would be required.

Richard.

 

[Richard Cornford]

VK wrote:

... . The statement alone that "returning null from a
constructor has no effect" demostrates such shiny lack
of a real javascript programming experience that I could
call [this] as "foobar property of foobarer" and I would
still remain in big plus by any "error-meter".

Do I take it from this little tirade that you think my suggestion that
your assertion that "If there is [return] statement in the constructor
and it is not "return this;", then return whatever pointed by this
statement" was false is so self-evidently not true my mere suggesting it
acts to completely destroy my credibility? That nothing you could
possible say, no matter how nonsensical, could be regarded as erroneous
in the light of it?

That would make it a pity I was correct in my assertion, as that rather
turns the credibility relationship on its head.

To be so absolutely confident in your beliefs that you will dismiss
correction out of hand while being so frequently demonstrated wrong is
less than rational.

Richard.

 

[VK]

VK wrote:

... . The statement alone that "returning null from a
constructor has no effect" demostrates such shiny lack
of a real javascript programming experience that I could
call [this] as "foobar property of foobarer" and I would
still remain in big plus by any "error-meter".

Do I take it from this little tirade that you think my suggestion that
your assertion that "If there is [return] statement in the constructor
and it is not "return this;", then return whatever pointed by this
statement" was false is so self-evidently not true my mere suggesting it
acts to completely destroy my credibility? That nothing you could
possible say, no matter how nonsensical, could be regarded as erroneous
in the light of it?

Hey, I'm just getting to be a good student of you... Three years ago I
would never write something of this level of silly pathetic, however
bad my current mood would be. But having three years in a row nearly
every post with an error or an ambigousity followed by 4-5 well
balanced "VK is ignorant / VK is halfweet / don't listen VK" - that
makes a change I guess. At some point you think to get your abuser by
any mean - rather than thinking on the matter itself. There is
something left of my old one though: so deeply sorry for the false
statement I made and for an abusive comment to your side. Think that I
just had my finger cut off for that - please humbly accept it

But: can you than explain why explicetly returning a reference to an
object from function-constructor does override default constructor
behavior: while returning a primitive is silently ignored? That is not
a "question with a trick" - I really would like to know, as well as to
know if this officially documented anywhere.

 

[Richard Cornford]

VK wrote:

... . The statement alone that "returning null from a
constructor has no effect" demostrates such shiny lack
of a real javascript programming experience that I could
call [this] as "foobar property of foobarer" and I would
still remain in big plus by any "error-meter".

Do I take it from this little tirade that you think my
suggestion that your assertion that "If there is [return]
statement in the constructor and it is not "return this;",
then return whatever pointed by this statement" was false
is so self-evidently not true my mere suggesting it acts
to completely destroy my credibility? That nothing you
could possible say, no matter how nonsensical, could be
regarded as erroneous in the light of it?

Hey, I'm just getting to be a good student of you...
Three years ago I would never write something of this
level of silly pathetic, however bad my current mood
would be. But having three years in a row nearly every
post with an error or an ambigousity followed by 4-5 well
balanced "VK is ignorant / VK is halfweet / don't listen
VK" - that makes a change I guess.

Three years of posting nonsense and disregarding the corrections made is
what earned you the type of reactions you get now. While others listen
learn form corrections and do not repeat their mistakes your reaction to
being corrected is to assert that questioning your understanding is akin
to questioning a claim that the sky is blue (here by implication and
literally on number of occasions).

At some point you think to get your abuser by
any mean - rather than thinking on the matter itself.

You perceive technical corrections as abuse? You are offended by the
implication that you may not know what you are talking about, even though
that has been demonstrated on such a regular basis that no objective
observer could be left with the impression that you do?

Even my regular suggestions that what you post is best explained by
mental illness is not actually abuse (or even a criticism as such) but
instead an attempt to make you aware of a problem you apparently suffer
from and which you could take steps towards having treated if you
appreciated you problem. (Though a characteristic of not being rational
may be not being able to perceive irrational behaviour as irrational).

You have, from the beginning, been given assistance, in the form of
explanations and corrections. The tone of that assistance may have
changed over time, but that is a direct consequence of your continued
attitude that you are the only person here who actually understands
javascript and so you do not need to change to correct yourself. We are
now at a point where attempting to improve your understanding has been
sufficiently demonstrated futile and now the best approach to you is to
attempt to mitigate the considerable harm you attempt to do to others.

There is something left of my old one though: so deeply
sorry for the false statement I made and for an abusive
comment to your side.

But not sorry for wasting so much of everyone's time arguing that you
were right all along? No sorry for squandering the time of the people
correcting you for the umpteenth time so it could not be used assisting
the more deserving? Not sorry for insulting Matt for no better reason
than seeing for himself how wrong you were?

Think that I just had my finger cut off for that -

As has happened numerous times in the past and will happen again and
again in the future. You are the only person in a position to do
something about that. You can either do something about starting to learn
javascript, or you can be silent on the subject.

please humbly accept it

If you were genuinely sorry you would do something about not repeating
your mistakes. You record suggests that having forced people to virtually
hammer the truth into you will teach you nothing beyond the single fact
(assuming your conceding the point actually represents you getting the
idea, which has not often been the case in the past) and you will make
the same mistake again, later today, tomorrow or the day after.

But: can you than explain why explicetly returning a
reference to an object from function-constructor does
override default constructor behavior: while returning
a primitive is silently ignored? That is not a "question
with a trick" - I really would like to know,

That is a question of motivation in language design, and so best asked of
the individuals responsible. For practical programming it is not
necessary to know why something is the case in the language being
programmed, only what is the case.

as well as to
know if this officially documented anywhere.

Why do you bother asking when you already know where the answer can be
expected to be found; ECMA 262, 3rd Ed. Section 13.2.2, clauses 7 and 8
of the specified algorithm for a function object's [[Construct]] method.

But of course you don't believe that ECMA 262 can be used to understand
the behaviour that can be expected from an ECMAScript implementation.

Richard.

 

[VK]

Three years of posting nonsense...

<snip>

I'm taking it as my apology for this particular case is accepted,
moving forward.

You perceive technical corrections as abuse?

A single-line post like "Do not listen VK" or "You have no idea about
JavaScript" can be hardly taken as "technical corrections". They are
especially hard to take then I know for sure that people issuing such
statements have very weak idea of many important JavaScript/JScript/DOM
programming aspects: yet positionning themselves as knowing everything
one has to know for client-side development. That's funny most of the
time, but sometimes the sh** hits the fan.

you don't believe that ECMA 262 can be used to understand
the behaviour that can be expected from an ECMAScript implementation.

It can, but very rarely: in application to myself that was twice in
four years, including the current case:
1) var statements
2) return null in constructor

13.2.2 [[Construct]]
When the [[Construct]] property for a Function object F is called, the
following steps are taken:

1. Create a new native ECMAScript object.

// Why not start then from "allocate memory for..."
// or even "processor executes assembly code..."
// For programming on a given language it is irrelevant
// For making an engine for a given language it is way not
// enough.

2. Set the [[Class]] property of Result(1) to "Object".

// On a human language it means that on step 1-2
// we are creating new Object() and not say new Function().

3. Get the value of the prototype property of the F.
4. If Result(3) is an object, set the [[Prototype]] property
of Result(1) to Result(3).
5. If Result(3) is not an object, set the [[Prototype]] property
of Result(1) to the original Object prototype object as
described in section 15.2.3.1.


function AnObject() {
alert(typeof AnObject.prototype); "object" of course
alert(this.prototype == AnObject.prototype); // false
alert(this.prototype == Object.prototype); // false
alert(this.prototype == Function.prototype); // false
}
var obj = new AnObject;

I'm out of ideas: what does step 4 mean? Is it a fancy way to say that
..constructor property of the newly created instance points to the
function-constructor (AnObject)? Something else?

6. Invoke the [[Call]] property of F, providing Result(1)
as the this value and providing the argument list passed
into [[Construct]] as the argument values.

// Create an empty instance of given "class", set this instance
// as current object ([this] value) for constructor,
// call the constructor with provided arguments.

7. If Type(Result(6)) is Object then return Result(6).
// else
8. Return Result(1).

// That is really valuable part, this is where my mistake was.
// So in order to override the default constructor behavior
// you always have to return something with typeof "object".

So in case like:
var obj = new AnObject();

ECMAScript to English translation:

1. Create an empty instance of AnObject object.

2. Set this instance as current object ([this] value).for AnObject
constructor.

3. Call AnObject constructor.

4. Optionally add fields and methods to the new instance:
or just leave it empty.

5. If there is not return statement then
return the result of step 4 (equivalent of "return this");
Else if there is return statement
and the return value is typeof "object" then
return a reference to that object.
If it is not "return this" and if you did not store
a reference to [this] somewhere on the step 4 then
the newly created instance will remain dereferenced and
eventually removed by the Garbage Collector.
Else
disregard return statement and return the result of
step 4 (equivalent of "return this");

The first if-clause, however obvious it may be, is important to mention
for Perl programmers - as well as for programmers of other languages
where function/sub returns either return value or (if no return
statement) the *result of execution of the last statement* in the
function body. That is why you see sometimes:
function AnObject() {
...
return this;
}
That seems making you nervous every time but it is not to upset
c.l.j. gurus: just another sample of a "languages' clinching".

 

[Richard Cornford]

<snip>

I'm taking it as my apology for this particular case is accepted,
moving forward.


A single-line post like "Do not listen VK" or "You have no idea about
JavaScript" can be hardly taken as "technical corrections".

They are not, they are just advice to the wider world, and they do not
appear as responses to your postes.

They are especially hard to take then I know for sure

But that is precisely your problem. What you know, what you "know for
sure" is rubbish. That is what got you apologising for posting evident
nonsense here. If you had not been so sure that you know what you were
talking about you might have bothered testing what return null actually
did in a constructor instead of declaring the suggestion that it would
not result in null being returned so obviously wrong as to destroy the
credibility of anyone who maintained such.

that people issuing such statements have very weak idea of many
important JavaScript/JScript/DOM

But they don't. You are the one with the very week idea of many
important aspects of javascript. What you think of the understanding of
others is o no real relevance as you just don't have nay applicable
knowledge with which to judge the knowledge of others.

programming aspects: yet positionning themselves as knowing
everything one has to know for client-side development.

The only thing being implied by the assertion that most of what you
post is nonsense, incomprehensible, false and/or the worst approach
available to any given issue is that someone has recognised you for
what you are.

That's funny most of the
time, but sometimes the sh** hits the fan.

you don't believe that ECMA 262 can be used to understand
the behaviour that can be expected from an ECMAScript implementation.

It can, but very rarely: in application to myself that was twice in
four years, including the current case:
1) var statements
2) return null in constructor

13.2.2 [[Construct]]
When the [[Construct]] property for a Function object F is called, the
following steps are taken:

1. Create a new native ECMAScript object.

// Why not start then from "allocate memory for..."

Because allocating memory would be implementation specific and the
standard for javascript only defines behaviour (and how would you
allocate memory in an implementation written in Java or javascript?).

// or even "processor executes assembly code..."
Ditto.

// For programming on a given language it is irrelevant
// For making an engine for a given language it is way not
// enough.

You are the only person who has made the mistake of thinking that the
language specification is a javascript engine specification. You will
find that any one of your misconceptions will tend to act to get in the
way of your understanding new information and so generate new
misconceptions.

2. Set the [[Class]] property of Result(1) to "Object".

// On a human language it means that on step 1-2
// we are creating new Object() and not say new Function().

3. Get the value of the prototype property of the F.
4. If Result(3) is an object, set the [[Prototype]] property
of Result(1) to Result(3).
5. If Result(3) is not an object, set the [[Prototype]] property
of Result(1) to the original Object prototype object as
described in section 15.2.3.1.


function AnObject() {
alert(typeof AnObject.prototype); "object" of course
alert(this.prototype == AnObject.prototype); // false

Object objects do not have - prototype - properties. Those properties
are only natively provided on Function objects. Thus - this.protoype -
can be expected to be undefined, and so not equal to anything but
another undefined or null. As I have repeatedly said; you failure to
appreciate the nature, and role of, prototypes in javascript is
evident, and has lead to much nonsense issuing form you.

alert(this.prototype == Object.prototype); // false

The - this.prototype - property accessor will resole as undefined here
as well.

alert(this.prototype == Function.prototype); // false

And here.

}
var obj = new AnObject;

I'm out of ideas: what does step 4 mean?

It means what it says; that the internal [[Prototype]] property of the
object is set the value of the - prototype - property of the
constructor function (except when that value is not an object).

Is it a fancy way to say that
.constructor property of the newly created instance points to the
function-constructor (AnObject)? Something else?

It mans what it says. It really is not that complicated, though your
inability to differentiate between the property that refers to the root
of the prototype chain and the - prototype - property of constructors
will tend to render it incomprehensible for you.

6. Invoke the [[Call]] property of F, providing Result(1)
as the this value and providing the argument list passed
into [[Construct]] as the argument values.

// Create an empty instance of given "class",

The instance was created in step 1, and it is an instance of the native
ECMAScript object.

set this instance
// as current object ([this] value) for constructor,
// call the constructor with provided arguments.

7. If Type(Result(6)) is Object then return Result(6).
// else
8. Return Result(1).

// That is really valuable part, this is where my mistake was.
// So in order to override the default constructor behavior
// you always have to return something with typeof "object".

The result is that - new - operations only ever return objects (or
throw exceptions).

So in case like:
var obj = new AnObject();

ECMAScript to English translation:

1. Create an empty instance of AnObject object.

Creates an instance of the native ECMAScript object.

2. Set this instance as current object ([this] value).for AnObject
constructor.

Are you omitting the assignment to the [[Prototype]] because it went
over your head?

3. Call AnObject constructor.

Would be better worded as "executes the function body", as that is
effectively what the internal [[Call]] method does.

4. Optionally add fields and methods to the new instance:
or just leave it empty.

5. If there is not return statement then
return the result of step 4 (equivalent of "return this");
Else if there is return statement
and the return value is typeof "object" then
return a reference to that object.
If it is not "return this" and if you did not store
a reference to [this] somewhere on the step 4 then
the newly created instance will remain dereferenced and
eventually removed by the Garbage Collector.
Else
disregard return statement and return the result of
step 4 (equivalent of "return this");

The first if-clause, however obvious it may be, is important to mention
for Perl programmers - as well as for programmers of other languages
where function/sub returns either return value or (if no return
statement) the *result of execution of the last statement* in the
function body. That is why you see sometimes:
function AnObject() {
...
return this;
}
That seems making you nervous every time but it is not to upset
c.l.j. gurus: just another sample of a "languages' clinching".

You have degenerated to gibberish again.

Richard.

 

[VK]

<snip>
Business first, the netiquette, apologies and the VK's issue in the
global politics just one step later: if you dont mind.

Because allocating memory would be implementation specific and the
standard for javascript only defines behaviour (and how would you
allocate memory in an implementation written in Java or javascript?).

Java and JavaScript do not provide direct memory *access* by using
language tools (unless a vulnerability exploit by specially constructed
code). But their objects are allocated in the same memory: as any other
objects in any other language. Positions 1 and 2 describe a generic
scavenger (~= heap) construction: very incompletely and in no relevance
to actual mechanics of say Microsoft JScript engine. But these
description defaults are really irrelevant to the *language* standard
compliance, as say it is irrelevant the bytes reading order on my
machine - as long as new Object(); doesn't crash your UA.
So I keep wondering that this part is doing here.

Ditto


<after your explanations snip step 4, 5, 6 as irrelevant to the
*language*, still roaming below it>

As I have repeatedly said; you failure to
appreciate the nature, and role of, prototypes in javascript is
evident

The role of .prototype or the role of [[Prototype]] ?
I do appreciate a lot the prototype property in JavaScript (though I'm
using it only for default objects augmentation, so rather occasionally
I'm afraid).
At the same time I couldn't care less about [[Prototype]] or [[Class]]
- unless one day I will be hacking a script engine and by some mystery
it will appear to be the ECMAScript engine.

So steps 1, 2, 3, 4, 5 for the *language* user are only one step:

1. Create an empty object and define F as its constructor.

6. Invoke the [[Call]] property of F, providing Result(1)
as the this value and providing the argument list passed
into [[Construct]] as the argument values.

Very curly said but now has some sense. To bring even more sense into
it:

6. (really 2. now) Set the Result(1) as current object for F
constructor and call the constructor with the provided arguments (if
any).
btw: if you don't have any arguments to pass, you can omit parenthesis
in the constructor call:
var obj = new MyObject();
or
var obj = new MyObject;
are equivalent. I don't know where ECMA says about, but sure they do.
Just came in my mind while typing.

The instance was created in step 1, and it is an instance of the native
ECMAScript object.

An object, which is not an Object or Function or anything else, is not
an object in the programming sense. That is still below the language
level so it doesn't bother us; but I mentioned it already.

4. Optionally add fields and methods to the new instance:
or just leave it empty.

5. If there is not return statement then
return the result of step 4 (equivalent of "return this");
Else if there is return statement
and the return value is typeof "object" then
return a reference to that object.
If it is not "return this" and if you did not store
a reference to [this] somewhere on the step 4 then
the newly created instance will remain dereferenced and
eventually removed by the Garbage Collector.
Else
disregard return statement and return the result of
step 4 (equivalent of "return this");

You have degenerated to gibberish again.

*Now* what's wrong? That is the formal algorithm from the language
point of view (or did you mean "gibberish" about some people using -
return this - in their constructors and you pointing out to that?)

Here is the code to illustrate the formal algorithm or -return-
statement treatment in javascript constructor:

<html>
<head>
<title>Demo</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
var myVar = true;

function MyObjectOne() {
}

function MyObjectTwo() {
return new String('foobar');
}

function MyObjectThree() {
return 'foobar';
}

function init() {
var objOne = new MyObjectOne;
var objTwo = new MyObjectTwo;
var objThree = new MyObjectThree;

// Default behavior:
alert(objOne instanceof MyObjectOne); // true

// Overloaded constructor:
alert(objTwo instanceof MyObjectTwo); // false

// return value is not an object: fall back to
// the default behavior:
alert(objThree instanceof MyObjectThree); // true

alert(objOne); // "[object Object]"

alert(objTwo); // "foobar"

alert(objThree); // "[object Object]"
}

window.onload = init;
</script>
</head>

<body>

</body>
</html>

 

[John G Harris]

Again: what language are you talking about? JavaScript? Java? C++? C#?
VB? They all have "only one object type" in your terms. An Object
instance and say Applet instance in JVM are not marker by different
colors they are not "one is squared and other is rounded". They are
not, trust me. The same structure with different set of properties and
references to other objects.

<snip>

In Java an object consists of a fixed number of bytes, possibly
containing pointers to objects consisting of a fixed number of bytes,
possibly containing pointers ... .

The fixed number of bytes is decided by the compiler when it reads the
class definition. If two objects have a different fixed number of bytes
then they can't possibly belong to the same Java class. So yes, one is
'squared' and the other is 'rounded'.

We can't trust you here because you are wrong.

The Object object is contained in all other objects; all of its methods
and properties are available in all other objects.

'The' Object object is *not* contained in all other objects. What all
objects have is a prototype chain that is guaranteed, in ECMAScript v3,
to end with the same very special object. This special object has
several properties that are functions. Some of these functions implement
operations such as hasOwnProperty that cannot be coded by us.

The reason all objects have something in common is because they all
share this special prototype object. (In ECMAScript v3).

Every object "first
born" as a naked empty generic Object instance and it becomes something
different during the instantiation process. Yet every object remembers
its "babyhood": so besides of being an instanceof its class it also an
instanceof Object.

<snip>

A new-born, naked, object is not an Object instance because it has not
been processed by the constructor function named Object. If it is
processed by MyObject, Date, Array, or anything else except Object, it
never will be an Object instance.

A new-born object has nothing to remember. It is given things to
'remember' during the construction process : its prototype chain, its
programmer-defined properties, etc.


John

 

[Richard Cornford]

<snip>
Business first, the netiquette, apologies and the VK's issue in the
global politics just one step later: if you dont mind.



Java and JavaScript do not provide direct memory *access* ...

<snip>

So there would be no sense in a document that specifies how javascript as
a language is supposed to behave mentioning something that could not be
implemented in languages that could be used to implement javascript. It
was irrational of you to propose the inclusion of that impractical
irrelevance in the specification.

... . But these description defaults are really irrelevant
to the *language* standard compliance, ...
Precisely.

So I keep wondering that this part is doing here.

Your mentioning memory allocation was a pointless inclusion on your part,
and if you are wondering why you mentioned it its looks you will never
satisfactorily explain it to anyone else.

Ditto

<after your explanations snip step 4, 5, 6 as irrelevant
to the *language*, still roaming below it>

You are a fool if you cannot see that the language needs to be precise
about what is going to happen if someone assigns a non-object property to
the constructor's - prototype - property. However, as you have once again
demonstrated that you don't comprehend the role of prototypes in the
language, and given your record an leaving huge logical holes in the
algorithms you implement, I should not be surpassed at yet another
demonstration of your folly.

As I have repeatedly said; you failure to
appreciate the nature, and role of, prototypes
in javascript is evident

The role of .prototype or the role of [[Prototype]] ?

The role of prototypes is manifest in the relationship between the two.

I do appreciate a lot the prototype property in JavaScript

Bullshit. What you have written above directly contradicts that. In this
very thread you posted:-

| alert(this.prototype == AnObject.prototype); // false

- as some sort of attempt to demonstrate something (and that was nowhere
near the first time you have done so). The inevitability of the -
false - result is lost on you.

(though I'm using it only for default objects augmentation,
so rather occasionally I'm afraid).

And you have the nerve to comment of the relative simplicity of other
approaches, when you are letting your ignorance of a fundamental aspect
of javascript keep you from seeing where the real simplicity is to be
found in object creation.

At the same time I couldn't care less about [[Prototype]]
or [[Class]]

They are both there for very good reasons. Indeed everything in the
specification is there for a very good reason, but if you prefer to
ignore them you will find yourself back here again being shown up for
posting your fictions in the guise of facts.

- unless one day I will be hacking a script engine and by
some mystery it will appear to be the ECMAScript engine.
LOL.

So steps 1, 2, 3, 4, 5 for the *language* user are only
one step:

It is not the style of ECMA 262 to combine too many operations into a
single step in its algorithms. That is probably a good thing as it avoids
them becoming ambiguous or accidentally skipping possibilities.

1. Create an empty object and define F as its constructor.

There is no assignment to a - constructor - property in the construction
of an object in javascript. (The - constructor - property is accounted
for in Section 13.2, during the creation of function objects). It is the
assignment to the [[Prototype]] property (that you have just dismissed as
irrelevant) that explains how the new object comes to inherit a -
constructor - property.

Also, labelling a new instance of the native ECMAScript object "empty" is
likely to be confusing as the assignment to the [[Prototype]] property
brings with it a number of other properties, and so the object will not
behave as if it was empty.

6. Invoke the [[Call]] property of F, providing Result(1)
as the this value and providing the argument list passed
into [[Construct]] as the argument values.

Very curly said but now has some sense.

It is astounding to see the extent to which information plus the
application of your mental processes results in your understanding less.

To bring even more sense into it:

Fat chance.

6. (really 2. now) Set the Result(1) as current object

There is no point in introducing your bogus "current object" jargon here.
The existing "providing Result(1) as the *this* value" is sufficient, and
does not introduce the questions of how the global object gets to be "the
current object" in execution contexts which do not result from the
execution of a function as a method or a constructor, and it doesn't
raise the question of what sense "current object" could have in
functional and/or procedural javascript code.

for F constructor and call the constructor with the
provided arguments (if any).
btw: if you don't have any arguments to pass, you can
omit parenthesis in the constructor call:
var obj = new MyObject();
or
var obj = new MyObject;
are equivalent. I don't know where ECMA says about,
but sure they do.

ECMA 262, 3rd ed. Section 11.2.2;the production rules and algorithms for
the - new - operator, of course.

Just came in my mind while typing.

That doesn't surprise me, given how directionless your mind is.

An object, which is not an Object or Function or anything
else, is not an object in the programming sense.

What are you talking about now? The native ECMAScript object is an
object. In fact it is the only type of object in javascript, and function
objects are also instances of the native ECMAScript object (inevitably as
it is the only object type in javascript).

That is still below the language level so it doesn't
bother us; but I mentioned it already.

It read more like irrelevant ravings.

4. Optionally add fields and methods to the new
instance:
or just leave it empty.

5. If there is not return statement then
return the result of step 4 (equivalent of "return this");
Else if there is return statement
and the return value is typeof "object" then
return a reference to that object.
If it is not "return this" and if you did not store
a reference to [this] somewhere on the step 4 then
the newly created instance will remain dereferenced and
eventually removed by the Garbage Collector.
Else
disregard return statement and return the result of
step 4 (equivalent of "return this");

You have edited out a big chunk of what I quoted here without marking the
edit. That is disingenuous to say the least. However, I suppose
disingenuous quoting may be as easily attributed to insanity (that is,
you don't know any better because you cannot follow simple sequences of
statements) as it could to dishonesty.

*Now* what's wrong?

The material I was commenting upon (that you edited out from above this
quite) degenerated into meaningless gibberish. That is, it was an
aggregation of words in a form that did not always qualify as sentences
and/or from which meaning could not be derived.

That is the formal algorithm from the language
point of view

The quote of yours I was commenting upon (that you have edited to give a
dishonest impression of what I was commenting upon) was not a formal
algorithm of anything. And the quote you retained does not really qualify
as one either, though given the compute code you write I can see how you
might mistake it for one.

(or did you mean "gibberish" about some people using -
return this - in their constructors and you pointing
out to that?)

No, I was commenting upon the text that I quoted directly above the
comment that I made (the text you edited out).

Here is the code to illustrate the formal algorithm

<snip>

And here is the code that demonstrates that the [[Construct]] method
never assigns a value the - constructor property of an object it
creates:-

function AnObject(){
;
}

var obj = new AnObject();

AnObject.prototype.constructor = null;

alert(obj.constructor);

- And unlike you I am capable of explaining how that demonstrates that
no - constructor - property is assigned to the object during its
construction:

If a property is assigned to an object and the object does not have that
property itself (even if one of its prototypes does have the property) a
new property of the object is created. Thus if a - constructor - property
was assigned a value during the creation of an object that property would
mask any property on the object's prototype chain. Once the object was
created no assignment to a prototype of the object could influence the
value returned by reading that property of the object. But here assigning
a value to the - constructor - property of the object referred to by
the - prototype - property of the constructor results in reading the -
constructor - property of the _previously_ created object instance
reflecting the value just assigned.

The ECMA 262 algorithm fully explains what happens during the
construction of the object. While your efforts are still making
statements that are demonstrably false, even though you have read (even
cited) the algorithm.

Richard.

 

[Michael Winter]

Richard Cornford wrote:
[snip]

You perceive technical corrections as abuse?

A single-line post like "Do not listen VK" or "You have no idea about
JavaScript" can be hardly taken as "technical corrections".

Who has made a single line reply like that? Any regular in this group
would quote you, at the very least!

They are especially hard to take then I know for sure that people
issuing such statements have very weak idea of many important
JavaScript/JScript/DOM programming aspects:

Though in the past I haven't agreed with Richard's diagnoses of insanity
(I've preferred stubbornness or stupidity), I think that might just
change my mind.

yet positionning themselves as knowing everything one has to know for
client-side development.

Who's done that? You're the most intransigent person I've ever
encountered, despite being corrected an innumerable number of times.

[snip]

It can, but very rarely: in application to myself that was twice in
four years,

You either have a very poor memory, or you are deluded.

[snip]

13.2.2 [[Construct]]
When the [[Construct]] property for a Function object F is called, the
following steps are taken:

1. Create a new native ECMAScript object.

// Why not start then from "allocate memory for..."

That would be too specific. The ECMAScript specification defines
behaviour. Implementations may implement the language however they wish
so long as one can expect the described behaviour.

// or even "processor executes assembly code..."

Now you're just being facetious.

// For programming on a given language it is irrelevant

No, it isn't.

// For making an engine for a given language it is way not
// enough.

No, it isn't.

For want of a better expression, that algorithm step describes the
creation of a "bare" object: there are no internal properties set (such
as [[Value]] and [[Prototype]]), some of the internal methods like
[[Get]] and [[Put]] are, but not special methods such as
[[HasInstance]], [[Call]], and the unique [[Get]] method of array instances.

2. Set the [[Class]] property of Result(1) to "Object".

// On a human language it means that on step 1-2
// we are creating new Object() and not say new Function().

Not at all. Creating an Object object involves setting the prototype
chain and calling the constructor function, neither of which is
performed in this step nor the preceding one.

Note that the constructor functions of built-in and host objects may
(and do) replace the value of the [[Class]] property, so don't be
confused by the value 'Object'.

3. Get the value of the prototype property of the F.
4. If Result(3) is an object, set the [[Prototype]] property
of Result(1) to Result(3).
5. If Result(3) is not an object, set the [[Prototype]] property
of Result(1) to the original Object prototype object as
described in section 15.2.3.1.
[snip]

I'm out of ideas: what does step 4 mean?

The internal [[Prototype]] property represents the prototype chain. It
is through this property that the [[Get]] method will search when
looking for a property in a member accessor (if that property is not
present on the object itself).

For example,

function myFunction() {}

myFunction.valueOf()

The identifier, myFunction, will be resolved against the scope chain to
obtain a reference to a function object. The [[Get]] method will then be
called on that object with argument 'valueOf'. Function object instances
do not have valueOf properties, so the [[Get]] method will check if
there is a non-null [[Prototype]] property and, if there is, call its
[[Get]] method with the same argument. The [[Prototype]] property of a
function instance is the Function prototype object. This object will not
have a valueOf property either, so again a check will be made for
another [[Prototype]] property. The [[Prototype]] property of the
Function prototype object is the Object prototype object. This object
does have a valueOf property, and (eventually) the [[Call]] method of
this property value will be called.

[snip]

6. Invoke the [[Call]] property of F, providing Result(1)
as the this value and providing the argument list passed
into [[Construct]] as the argument values.

// Create an empty instance of given "class",

No, just an empty ECMAScript native object.

// set this instance as current object ([this] value) for constructor,
// call the constructor with provided arguments.

The term "current object" aside (which still has no intrinsic meaning),
that's about right, though if that was an overall summary, you missed
some important steps.

7. If Type(Result(6)) is Object then return Result(6).
// else

That's implied, is it not? Would it really be necessary to write:

if (condition) {
return ...;
} else {
return ...;
}

instead of

if (condition) {
return ...;
}
return ...;

? I think not.

8. Return Result(1).

// That is really valuable part, this is where my mistake was.
// So in order to override the default constructor behavior
// you always have to return something with typeof "object".

No, one must return /an/ object: typeof null is also 'object'.

So in case like:
var obj = new AnObject();

ECMAScript to English translation:

1. Create an empty instance of AnObject object.

I don't think one could really say that the object could be considered
an AnObject object until the constructor function has been run (and
completed successfully). At this point, the object is just a native
ECMAScript object with the [[Class]] and [[Prototype]] properties set
(assuming that's your implication), and that means it can hardly be
called empty.

2. Set this instance as current object ([this] value).for AnObject
constructor.

That phrase again...

3. Call AnObject constructor.

4. Optionally add fields and methods to the new instance:
or just leave it empty.

Sorry? Once the constructor has been called, there are only two
operations left: determine the returned type, and depending on that
result, either return the object created in step 1 or the object
returned from the constructor function.

5. If there is not return statement then
return the result of step 4 (equivalent of "return this");
Else if there is return statement
and the return value is typeof "object" then
return a reference to that object.

That's complicating things unnecessarily: if there is no return
statement, the constructor function will return undefined just like any
other function. As such a value isn't an object, it would be treated in
the same way as other primitives.

[snip]

The first if-clause, however obvious it may be, is important to mention
for Perl programmers

I don't see why. Any sensible programmer from any language background
should learn this language rather than assume they know how it works
(because they probably don't, just like anyone else first time around).

[snip]

Mike

 

[Richard Cornford]

VK wrote:

Though in the past I haven't agreed with Richard's diagnoses
of insanity (I've preferred stubbornness or stupidity), I
think that might just change my mind.

<snip>

I considered stubbornness and stupidity for a long time, and I also
considered that VK's problem was a very limited comprehension of English
(probably resulting from it being a second+ language) but in the end none
of them (or even all of them) were capable of fully explaining his posts
(particularly the very illogical 'reassign' he demonstrates, or the truly
incomprehensible 'streams of consciousness' he sometimes posts).

I am not particularly keen to talk about it but I knew someone for whom
manic depression manifested itself in here early twenties. A cyclic
illness where long periods of lucidity are interrupter by interrupted by
what are (quite appropriately) called manic episodes. She was a very
intelligent woman (the only woman I have ever known who could reliably
beat me at chess) and quite interesting and entertaining to talk to. But
as she went into the manic episodes you would be talking to her, and
everything would be going along the lines of a normal conversation, when
suddenly she would come out with a piece of reasoning so disjointed that
is was difficult to attribute it to the same person.

After experiencing a couple of cycles these first steps on the descents
into madness became very recognisable, I would think "here we go again",
and within a week she would have descend so far as to have been committed
to hospital for a couple of months to 'recover'.

There is something about the style of 'reasoning' I experienced than that
has become recognisable in VK's posts. They are just too far from the
products of the thought processes of a rational mind for hits of mental
illness to be dismissed.

Richard.

 

[VK]

There is no point in introducing your bogus "current object" jargon here.

I mostly lost the interest to this discussion: I learned an important
thing (at least important for me) about return values in constructors,
and there is nothing more to learn or discuss on the subject. Your
phantasmagorias about some "native ECMAScript object" and its extremely
important for the language yet invisible in the language [[properties]]
are giving me too much of a heartburn, sorry.

Outside of the main topic about function-constructors you'd like to
point that you are the one with a proprietary jargon used in ECMAScript
specs and unknown in any regular language references.

Netscape Client-Side JavaScript Reference (archive copy):

<http://docs.sun.com/source/816-6408-10/ops.htm#1043482>
The this keyword refers to the current object.
In general, in a method this refers to the calling object.

<http://docs.sun.com/source/816-6408-10/stmt.htm#1004910>
with
Establishes the default object for a set of statements.


Core JavaScript 1.5 Reference
<http://developer.mozilla.org/en/doc...nce:Operators:Special_Operators:this_Operator>
The this keyword refers to the context object (a.k.a. current object).
In general, in a method, this refers to the calling object.

<http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Statements:with>
Extends the scope chain for a statement.
(Seems as edited in rush as "extends the scope chain" has no practical
sense, I would bring it back to the Netscape's original form if you
don't mind).


Microsoft JScript reference:
<http://msdn.microsoft.com/library/d...html/8510a00b-2f14-4700-a276-4d9a523c5112.asp>

this Statement
Refers to the current object.

<http://msdn.microsoft.com/library/d...html/892c7621-ae9e-4c10-8adb-05532274b1ca.asp>
with Statement
Establishes the default object for a statement.

Do I have to keep going with more quotes?