Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Can I know if "new Func()" or "Func()" is called?

Reply
Thread Tools

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

 
 
Michael Winter
Guest
Posts: n/a
 
      10-11-2006
VK wrote:

> 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
 
Reply With Quote
 
 
 
 
Richard Cornford
Guest
Posts: n/a
 
      10-11-2006
runsun pan wrote:
> Jeremy wrote:
>> How about this:
>>
>> function TestConstructor()
>> {
>> if(this.constructor == TestConstructor)
>> alert("New Object");
>> else
>> alert("Function Call");
>> }
>>
>> Jeremy

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


 
Reply With Quote
 
 
 
 
Jeremy
Guest
Posts: n/a
 
      10-11-2006
Richard Cornford wrote:
>
> 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
 
Reply With Quote
 
VK
Guest
Posts: n/a
 
      10-11-2006
> 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.

 
Reply With Quote
 
VK
Guest
Posts: n/a
 
      10-11-2006
> > 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.

 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      10-11-2006
VK wrote:
>>> I just hate these Books of ECMA liturgies,

>>
>> And look where that gets you.

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


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

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


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.

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


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.


 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      10-11-2006
Jeremy wrote:
> Richard Cornford wrote:
>>
>> 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.

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


 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      10-12-2006
VK wrote:
<snip>
> ... . 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.


 
Reply With Quote
 
VK
Guest
Posts: n/a
 
      10-12-2006

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

 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      10-12-2006
VK wrote:
> Richard Cornford wrote:
>> VK wrote:
>> <snip>
>> > ... . 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.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
know can I know how much object has been created??? sayoyo@yahoo.com Ruby 2 03-31-2006 08:09 PM
"Microsoft Certification - It's how they know you know" MatrixVic MCSD 0 02-03-2006 02:52 AM
ISAKMP NAT problem (I know it can be done but don't know how) Rogier Mulder Cisco 1 01-13-2005 08:48 PM
I know, I know, I don't know Andries Perl Misc 3 04-23-2004 02:17 AM
Don know Perl, don't know what's broke - re - type1inst!! DP Perl 0 07-17-2003 10:22 PM



Advertisments