VK said:
OK, break!
I just hate these Books of ECMA liturgies,
And look where that gets you.
they affect me like a red color on a bull
I did a false statement about [this] nature (which
is a pointer to the current object, not to the default object).
As neither a technical terms in javascript that was not a false
statement, only a statement that was too vague to mean anything useful.
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. The scope chain being a well defined structure with a
precisely specified role in the resolution of Identifiers in
javascript, and so if it had been true your assertion that the newly
created object was added to the scope chain would have significant
implications. It would also have been an assertion that was
demonstrable. However, Matt and I have demonstrated that the newly
created object cannot be added to the scope chain by showing that the
effect on Identifier resolution that would follow from that action is
not present in javascript.
You did false statements about that is [this] pointing to in the
constructor
Did I? You cannot cite one from any of my previous posts in this
thread.
and about return values in the constructor.
No, I was correct in what I wrote.
So let's it put all
together once again:
You mean you want to have yet another go at expounding your
misconceptions.
If some function is called as an object constructor
var obj = new MyObject();
its (constructor's) current object is set to the newly created empty
instance of MyObject object.
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.
My error: calling "current object" as "default object".
The object is neither "current" nor "default". It is just the object
that results from the use of the - new - operator on a function
reference.
Your error: calling empty instance of MyObject object as "empty
instance of the default Object object".
I did not call it an empty instance of the default object. I called it
an instance of the native ECMAScript object (the only object type in
javascript) with its [[Prototype]] property set to the - prototype - of
the constructor.
There is no sense in "default Object" in a language where there is only
one object type.
<note>
That is not really your error: just another side effect of taking
ECMAScript specs as a *language specs*
To you it may be a mistake to take a language specification as a
language specification, others know better.
while it is *engine specs*.
If there is one thing ECMA 262 does not do it is specify how the
language is to be implemented.
The danger of it is that you can easily miss the level of the
language itself and fell through to the lower-level processes
making the engine to work.
Gibberish!
It is dangerous because lower of a certain level the differences
between different languages disappear: so you'll ending up
by stating generic language engine mechanics instead of
JavaScript-particular facts.
Your notion of "JavaScript particular facts" doesn't even agree with
reality.
Of course initially a generic Object object instance is created and
then patched by oid's, constructor references, then floating from
constructor to constructor to get its "flash" (object members).
More gibberish!
But it is true for JavaScript as well as for Java or C++: you're
missed the level of JavaScript specifics, go up!
You mean I know how javascript works to the extent of being in a
position to precisely predict how code will execute, while you cannot
even tell when the code you write actual does work or not (and
certainly could not explain how or why it odes what it does) and I am
the one who is missing something?
</note>
In the constructor you can assign members to this newly
created MyObject instance or just leave it empty. The latter
has not too much of practical sense,
It is manifest in your code that you have not yet perceived the role of
the constructor's prototype.
I just want to remind once again that
"this.property = something" inside a constructor is an optional step,
it doesn't make any "instantiation magic".
There is no need for you to worry about others adopting mystical
beliefs out of thin air, that is a failing that follows form your
insanity and not something that should be expected of the rational.
Now, what happened to your assertion about adding the newly created
object to the scope chain? Are you conceding that it was (as I stated)
utterly false by omitting that step from this 'description'?
If there is no [return] statement inside the constructor,
it returns the newly created MyObject instance reference
(equivalent of - return this; - statement). If there is a return
statement inside the constructor, it returns whatever the
return statement points to.
Once again, nonsense. The behaviour of return statements in functions
called as constructors is fully specified and the rule is; If the
function explicitly returns an object then the result of the - new
FucntionRef - expression is that object, else it is the newly created
object.
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.
One of the advantages of reading the language specification is that in
doing so you can learn the rules that actually do apply in situations,
including the use of return statements inside constructors. And those
rules are usually a lot les complex than the web of fictions that
represent your understanding of javascript.
If it is not - return this - and if we did not store a reference to the
newly created instance somewhere else in the constructor: in this
case the newly created MyObject instance will remain dereferenced
and soon removed by the Garbage Collector. The latter means that
we can call a function as a constructor and change our mind right
during the process. Practical importance if it is in an ability to
have singletons in JavaScript. Your error: saying that return value
has no effect for a constructor and that say - return null; - inside
a constructor has no effect.
Was that my error? The evidence says otherwise.
A small sample to illustrate your latter mistake:
<script type="text/javascript">
function MyFriendlySingleton() {
if ((this instanceof MyFriendlySingleton) != true) {
return null;
}
else if (MyFriendlySingleton.$_$) {
return MyFriendlySingleton.$_$;
}
else {
MyFriendlySingleton.$_$ = this;
this.property = 'foobar';
}
}
var obj1 = new MyFriendlySingleton();
var obj2 = new MyFriendlySingleton();
var obj3 = MyFriendlySingleton();
window.alert(obj1 === obj2);
window.alert(obj3 === null);
</script>
It is no wonder you struggle to understand the simplest concepts. Here
you have attempted to 'demonstrate' something with an overly complex
mass of code, when an absolutely simple case would have proved you
wrong, and you have failed to do the one thing that is significant to
the question; return null from a function called as a constructor. In
fact you have tried to arranged that you function only returns null
when it is _not_ called as a constructor, which demonstrated nothing
significant as the return values from functions not called as
constructors are the value returned (and absolutely expected to be so).
Overall I see it as a valuable experience exchange
The only valuable lesson you could learn is a proper appreciation of
how very little you understand about javascript and computer
programming. Learning that lesson is the only thing that will stop you
from being a worthless waste of time.
(I learned the right term to use for [this],
Apparently not.
you've learned how does a function-constructor
really work in *JavaScript* - not in ECMAScript specs).
No, I learned that half a decade ago, and you probably don't understand
it even now I have explained the actual rule.
Now concerning practical needs to distinguish between Func() and
new Func() calls inside Func() itself (that is what OP wanted).
Ah, now we have the opinion of the worst programmer I know of.
I cannot comment on OP's real needs as he did not tell us
about it.
Yet you feel yourself able to tell him how he should be approaching his
problem, even though he has not explained what his problem actually is.
And recommended a semi-functional scripted hack where something as
simple as a common naming convention could answer the situation
satisfactorily. (That is; it is common to use initial uppercase
characters on the names of functions intended to be used as
constructors so anyone calling a function with an initial uppercase
character directly should be expecting problems, or be called
incompetent, as should anyone designing functions to be called directly
and used as constructors).
In my code it is often useful to monitor [this] nature in the classy
inheritance emulation.
As you do not have a clue as to what to expect from javascript (being
utterly ignorant of the technicalities of the language) it does not
surprise me that you fell you have that need. On the other hand
computer programmers will not have the same experience.
Yes, it is not the CC scope management you are using,
You don't know what you are talking about (and as you are making your
own terminology up off the top of your head again it is unlikely that
many others will either).
it is another approach. I like it better for the simplicity and
extendibility, but it's my strictly private opinion.
You have just posed a mass of needlessly complex code and you consider
it represents "simplicity"? In javascript the simple approach to
'classes' and class hierarchies is through assigning objects to the
prototypes of constructors, or modifying the prototypes that start
with.
An approach that gets as far as using the - call - or - apply - methods
is already two or three steps into complex elaboration. You use such an
approach because you don't understand javascript well enough to see the
simplicity where it is, and instead just regurgitate an approach that
you were shown once and that 'works', regardless of the fact that it is
inappropriately complex for the simple applications you use it with.
The point of actually understanding javascript is to be able to see the
approach most applicable to a situation. And so be able to write code
that is precisely no more complex than it needs to be. What you label
"CC" is more complex than is suitable for the vast majority of cases
(though not as complex as you perceive it, but that it because it
requires a real technical understanding of the langue in order to work
with, not the mush of misconceptions and fictions you attempt to
perceive it with), but what you are doing is also fat too complex for
the majority of cases.
... You are free to sign it it off to the limitations of my humble mind.
Personal insanity is still the explanation of your posts that most
closely fits the facts.
Richard.
