«

Richard Cornford wrote:
> 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.

<return statement in function-constructor>
> 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".

VK wrote:
> Richard Cornford wrote:
> > 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 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.



> <return statement in function-constructor>
> > 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.

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

> > 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?).

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.

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

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>

In article <. com>, VK
<> writes

<snip>
>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
--
John Harris

VK wrote:
> <snip>
> Business first, the netiquette, apologies and the VK's issue in the
> global politics just one step later: if you dont mind.
>
>> > 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?).
>
> 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.

>>> // For programming on a given language it is irrelevant
>>> // For making an engine for a given language it is way not
>>> // enough.
>
> 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.

>> 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.

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.

>> You have degenerated to gibberish again.
>
> *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.

VK wrote:

> 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]

> <return statement in function-constructor>
>> 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,

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

Michael Winter wrote:
> VK wrote:
<snip>
>> 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.
<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.

Richard Cornford wrote:
> 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/docs/Core_JavaScript_1.5_Reference:Operators:Special_Op erators: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/default.asp?url=/library/en-us/script56/html/8510a00b-2f14-4700-a276-4d9a523c5112.asp>

this Statement
Refers to the current object.

<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/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?