"x.constructor == Foo" vs "x instanceof Foo"

[kj]

My book (Flanagan's javascript: The Definitive Guide, 5th ed.)
implies on page 111 that the following two constructs are equivalent:

( x.constructor == Foo )

and

( x instanceof Foo )

The author states that the instanceof operator computes its result
by examining the value of its first argument's the constructor
property.

However, I've recently ran into a situation that contradicts this.

I've been trying to understand jQuery better, with the aid of
Firefox's Firebug debugger. At one breakpoint, there's one variable
(I'll call it x) for which

x instanceof jQuery

is true, but

x.constructor == jQuery

is false.

In fact, x.constructor is Object, but (Object instanceof jQuery)
is false.

Could anyone explain to me what's going on?

TIA!

Kynn

--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.

[liamgegan]

On Jan 28, 8:47 am, kj <[e-mail]:

My book (Flanagan's javascript: The Definitive Guide, 5th ed.)
implies on page 111 that the following two constructs are equivalent:

( x.constructor == Foo )

and

( x instanceof Foo )

The author states that the instanceof operator computes its result
by examining the value of its first argument's the constructor
property.

However, I've recently ran into a situation that contradicts this.

I've been trying to understand jQuery better, with the aid of
Firefox's Firebug debugger. At one breakpoint, there's one variable
(I'll call it x) for which

x instanceof jQuery

is true, but

x.constructor == jQuery

is false.

In fact, x.constructor is Object, but (Object instanceof jQuery)
is false.

Could anyone explain to me what's going on?

TIA!

Kynn

--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.

I know that there are difference in the way that instanceof is
determined vs. x.constructor. In this instance it sounds like it's an
issue with the way that JQuery handles it's extends functionality. Not
having used JQuery a great deal, could you shed some light on the way
that JQuery extends?

[kj]

In <7a**********************************@e10g2000prf. googlegroups.com"li*******@gmail.com" <li*******@gmail.comwrites:

>I know that there are difference in the way that instanceof is
determined vs. x.constructor. In this instance it sounds like it's an
issue with the way that JQuery handles it's extends functionality. Not
having used JQuery a great deal, could you shed some light on the way
that JQuery extends?

That went over my head! :-) But I'll do my best...

The jQuery object does have an extend method, if that's what you're
asking. It can be invoked in a few ways, but probably the most
general one is something like

jQuery.extend( bool, target, obj1, obj2, obj3 ... );

If bool is false, extend copies values from obj1, obj2, obj3, etc.
into the corresponding slots in target. If bool is true, instead
of copying it extends the slots when the the contents of both the
target and source slots are themselves are objects. (That's a very
broad-strokes description!)

But I find your question also puzzling, because it suggests that
"extends" is a function that, when available, gets called automatically
by the interpreter in certain situations, just like, e.g., valueOf
or toString. If this is the case then I'm even more mystified than
before, because I've never heard of such a thing. (FWIW, Flanagan
doesn't even *mention* extend.)

Kynn

P.S. I really need to get myself an authoritative reference on
JavaScript... I thought that Flanagan's book was it, but just
today I've run into a few topics (such as the const keyword) that
Flanagan doesn't even *mention*. I'm wondering if "extend" will
be another such blind spot...

--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.

[Joost Diepenmaat]

Joost Diepenmaat <jo***@zeekat.nlwrites:

What? Just. No. That's just even *more* confusing. Why not do this if
you want real prototyping:

var SubProto = {};
var SuperProto = extend(SubProto);
var super = extend(sub);

I meant:

var SubProto = {};
var SuperProto = extend(SubProto);
var super = extend(SuperProto);

Sorry about the confusion.

Joost.

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

[imported correction from <87************@zeekat.nl>]

>Why not do this if you want real prototyping:

var SubProto = {};
var SuperProto = extend(SubProto);
var super = extend(SuperProto);

`super' is a reserved word.

Nonsense. User-defined objects should inherit from prototype (Object)
objects, not from constructor (Function) objects.
[...]

Please ignore that, I was overlooking that you are using Object objects already.

>and just forget about "new constructor()" altogether and use extend() to
create *all* objects. [...]

While the identifiers are confusing and even misleading, it certainly is an
interesting idea: One Object object would inherit from the other, indeed.
However, it looks as if there was a bug in it and I just don't see it yet.
PointedEars

[Dr J R Stockton]

In comp.lang.javascript message <fn**********@reader2.panix.com>, Sun,
27 Jan 2008 23:15:28, kj <so***@987jk.com.invalidposted:

>
P.S. I really need to get myself an authoritative reference on
JavaScript...

So get ISO/IEC 16262, free as a PDF.

I thought that Flanagan's book was it, but just
today I've run into a few topics (such as the const keyword) that
Flanagan doesn't even *mention*. I'm wondering if "extend" will
be another such blind spot...

Remember that a script engine author needs to know everything in the
current and the imminent standards, and should also know what other
script engines actually do. For that, ordinary books cannot be expected
to suffice.

But a page author needs to know only those standards with which current
and recent script engines are compliant, and what the common browsers
actually do; if he knows anything else, he must keep the two sets of
knowledge quite separate in his mind.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zipTimo Salmi's Turbo Pascal FAQ.

[Joost Diepenmaat]

Joost Diepenmaat <jo***@zeekat.nlwrites:

Thomas 'PointedEars' Lahn <Po*********@web.dewrites:

>You miss the point. For example:

function Super() {}
Super.prototype.items = [];

function Sub() {}
Sub.prototype = new Super();

var sub1 = new Sub();
var sub2 = new Sub();
sub1.items.push(42);

// yields [42], instead of [] as it should
sub2.items

That's expected. Prototypes aren't templates, they're objects in their
own right, and sharing a prototype, which is exactly what constructors
do to their generated objects, means you're sharing the prototype's
properties until you override them by setting them in the super
object. ^^^^^

I meant: sub object

Joost.

[RobG]

On Jan 28, 10:39*am, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:
[...]

One way to do it properly is this oft-recommended approach:

* function extend(P)
* {
* * function Dummy() {}
* * Dummy.prototype = P;
* * return new Dummy();
* }

Richard Cornford suggested that can be written more efficiently by
reusing the Dummy constructor:

var extend = (function(){
function Dummy(){}
return (function(P){
Dummy.prototype = P;
return new Dummy();
});
})();

<URL:
http://groups.google.com.au/group/co...965e62bfb3aa9f

>

--
Rob

[Thomas 'PointedEars' Lahn]

RobG wrote:

[...] Thomas 'PointedEars' Lahn [...] wrote:

>One way to do it properly is this oft-recommended approach:

function extend(P)
{
function Dummy() {}
Dummy.prototype = P;
return new Dummy();
}

Richard Cornford suggested that can be written more efficiently by
reusing the Dummy constructor:

var extend = (function(){
function Dummy(){}
return (function(P){
Dummy.prototype = P;
return new Dummy();
});
})();

<URL:
http://groups.google.com.au/group/co...965e62bfb3aa9f

Thanks, I was looking for that. However, you should consider that the
increased runtime efficiency gained by declaring the Dummy() constructor
only once is mitigated by the reduced memory efficiency caused by the
continued allocation of memory due to the closure. And since there are
more issues with closures than without them, I would avoid them here.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[Joost Diepenmaat]

Thomas 'PointedEars' Lahn <Po*********@web.dewrites:

Thanks, I was looking for that. However, you should consider that the
increased runtime efficiency gained by declaring the Dummy() constructor
only once is mitigated by the reduced memory efficiency caused by the
continued allocation of memory due to the closure. And since there are
more issues with closures than without them, I would avoid them here.

function Dummy(){}
function extend(proto) {
Dummy.prototype=proto;
return new Dummy();
}

No closure. Though I would be amazed if it would have any significant
impact on memory use.

Joost.

[Joost Diepenmaat]

Thomas 'PointedEars' Lahn <Po*********@web.dewrites:

Joost Diepenmaat wrote:

>Thomas 'PointedEars' Lahn <Po*********@web.dewrites:

>>Thanks, I was looking for that. However, you should consider that the
increased runtime efficiency gained by declaring the Dummy() constructor
only once is mitigated by the reduced memory efficiency caused by the
continued allocation of memory due to the closure. And since there are
more issues with closures than without them, I would avoid them here.

function Dummy(){}

^^^^^

>function extend(proto) {
Dummy.prototype=proto;

^^^^^

> return new Dummy();
}

No closure. [...]

I think there is one. `Dummy' was declared in the definition
context of `extend' that `extend' reproduces when it is called;
that is how a closure is defined.

If you're defining closures like that, every function that calls another
function, or accesses any other global property would be a closure:

function a() { alert() }
function b() { a(); }

My informal definition is that a closure is a function that keeps
references to objects that are defined in an outer lexical scope. Dummy
here is just a property of the global object, not a lexical variable.

Joost.

[Joost Diepenmaat]

Thomas 'PointedEars' Lahn <Po*********@web.dewrites:

Joost Diepenmaat wrote:

>Thomas 'PointedEars' Lahn <Po*********@web.dewrites:

>>Joost Diepenmaat wrote:
function Dummy(){}
^^^^^
function extend(proto) {
Dummy.prototype=proto;
^^^^^
return new Dummy();
}

No closure. [...]
I think there is one. `Dummy' was declared in the definition
context of `extend' that `extend' reproduces when it is called;
that is how a closure is defined.

If you're defining closures like that,

It is not my definition.

Then you won't mind me demonstrating that it's wrong:

function a() { alert("First") }

function b() { a() };

function a() { alert("Second") }

b();

>every function that calls another function,

Not every function. It depends on where the other function was defined.

See code above. We're accessing a global property, not a lexical
variable. The fact that the variable is a function doesn't matter.

>or accesses any other global property would be a closure:
[...]

That is correct. Probably that is why Flanagan made his oversimplifying
false statement.

Which statement?

Joost.

[Joost Diepenmaat]

Thomas 'PointedEars' Lahn <Po*********@web.dewrites:

JFTR: Quite the contrary. The above was _not_ to say that the
implementation was wrong, but the application of the implementation
*by you*.

Sharing a prototype's properties is not wrong by itself. It's what
prototypes in javascript are there for. The only time it's wrong is when
you actually don't want to share the properties, just copies. And
javascript does not provide any /built in/ mechanism to do that, so I
really don't see what you're complaining about.

Joost.

[Thomas 'PointedEars' Lahn]

Joost Diepenmaat wrote:

Thomas 'PointedEars' Lahn <Po*********@web.dewrites:

>Joost Diepenmaat wrote:

>>Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
Joost Diepenmaat wrote:
function Dummy(){}
^^^^^
function extend(proto) {
Dummy.prototype=proto;
^^^^^
return new Dummy();
}
>
No closure. [...]
I think there is one. `Dummy' was declared in the definition
context of `extend' that `extend' reproduces when it is called;
that is how a closure is defined.
If you're defining closures like that,

It is not my definition.

Then you won't mind me demonstrating that it's wrong:

The definition certainly is not wrong; maybe my interpretation of it in this
context is.

function a() { alert("First") }

function b() { a() };

function a() { alert("Second") }

b();

The second declaration for `a' overwrites the reference with one to another
Function object before b() is executed. ISTM you have just proved that
there is a closure :)

>>every function that calls another function,

Not every function. It depends on where the other function was defined.

See code above. We're accessing a global property, not a lexical
variable. The fact that the variable is a function doesn't matter.

That seems contradictory.

>>or accesses any other global property would be a closure:
[...]

That is correct. Probably that is why Flanagan made his oversimplifying
false statement.

Which statement?

That one cited in
<bc**********************************@1g2000hsl.go oglegroups.com>

Different thread, same source of confusion. Sigh. [psf 10.1]
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Joost Diepenmaat]

Thomas 'PointedEars' Lahn <Po*********@web.dewrites:

>function a() { alert("First") }

function b() { a() };

function a() { alert("Second") }

b();

The second declaration for `a' overwrites the reference with one to another
Function object before b() is executed. ISTM you have just proved that
there is a closure :)

I expected that reply and have prepared the following, demonstrating
that the lookup of a() in b() is done via dynamic, not lexical scoping.

function a() { alert("first") }

function b() { a() }

c = { a: function() { alert("second") } };
a();

with (c) {
a();
}

>>>every function that calls another function,
Not every function. It depends on where the other function was defined.

See code above. We're accessing a global property, not a lexical
variable. The fact that the variable is a function doesn't matter.

That seems contradictory.

Javascript variables that aren't declared (with var) in a function scope
or as a function argument are dynamic, defaulting to the global object's
property via whatever with() scopes are in place.

The same goes for functions: named functions defined in the global scope
are set as dynamic variables. Named functions defined within a with(X)
in the global scope are put in X. Named functions defined within a
function scope are lexical. I'm not sure what with() within a function
does.

Compare the above with:

function a() {
alert("first");
}

function b() { a() }

function c() {
function a() {
alert("second");
};
b();
}

a();
c();

>>>or accesses any other global property would be a closure:
[...]
That is correct. Probably that is why Flanagan made his oversimplifying
false statement.

Which statement?

That one cited in
<bc**********************************@1g2000hsl.go oglegroups.com>

Different thread, same source of confusion. Sigh. [psf 10.1]

I don't see the connection.

Joost.

[Thomas 'PointedEars' Lahn]

RobG wrote:

The amount of memory consumed in either case is trivial, I think the
performance gain (again, it's very small in one-of cases) outweighs
the memory consumed.

I don't know what you mean by "one-of cases", but my benchmarks show that
the performance gain is negligible, too. With 10'000 iterations, it's a gain of

30 ms in Firefox 2.0.0.11,
125 ms in IE 7, and
16 ms in Opera 9.24.

All running on Windows XP SP 2 on a Pentium M 740, 1.73 GHz, 1 GB RAM, 1.2
GB Swap (at the time of testing).

Benchmark source code:

function extend(P)
{
function Dummy() {}
Dummy.prototype = P;
return new Dummy();
}

var extend2 = (function()
{
function Dummy() {}
return function(P)
{
Dummy.prototype = P;
return new Dummy();
};
})();

if (typeof console == "undefined")
{
console = {log: function(s) { window.alert(s); }};
}

function Super() {}
function Sub() {}

var start = new Date();
for (var i = 10000; i--;)
Sub.prototype = extend(Super.prototype);
console.log(new Date() - start);

start = new Date();
for (i = 10000; i--;)
Sub.prototype = extend2(Super.prototype);
console.log(new Date() - start);
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[VK]

On Jan 28, 12:47 am, kj <[e-mail]:

My book (Flanagan's javascript: The Definitive Guide, 5th ed.)
implies on page 111 that the following two constructs are equivalent:

( x.constructor == Foo )

and

( x instanceof Foo )

The author states that the instanceof operator computes its result
by examining the value of its first argument's the constructor
property.

However, I've recently ran into a situation that contradicts this.

I've been trying to understand jQuery better, with the aid of
Firefox's Firebug debugger. At one breakpoint, there's one variable
(I'll call it x) for which

x instanceof jQuery

is true, but

x.constructor == jQuery

is false.

In fact, x.constructor is Object, but (Object instanceof jQuery)
is false.

Could anyone explain to me what's going on?

http://blogs.msdn.com/ericlippert/ar.../06/53352.aspx has it
all explained in details.

[kj]

In <47**************@PointedEars.deThomas 'PointedEars' Lahn <Po*********@web.dewrites:

I wonder how long it will take until everybody recognizes that
Flanagan actually has no clue what he is writing about.

Well, clearly I'm one of those who was pretty slow at figuring this
out... (Though, irrespective of matters of accuracy, I've never
been not fond of Flanagan's ponderous tome.)

But if not Flanagan's book, then what?

Is there a better alternative for someone looking for an authoritative
JavaScript reference book? I suppose I could use the ECMA specs...
But is there something closer to JavaScript (whatever that is)?

I should say that I dislike most computer language "bibles" that
one can buy. It is clear that most of them aim for *bulk* rather
than substance. (It wouldn't surprise me if some of them used
thicker paper than normal, to create an imposing "authoritative"
presence in bookstores' shelves!)

So, to be more specific, my gold-standard for language reference
books is Harbison and Steele's "C: a reference manual". It's as
authoritative as any formal C specification, but significantly more
readable, without any superfluous handholding fluff... (The also
excellent Python Reference Manual by van Rossum is a very close
second.)

Is there something like that for JavaScript?

kynn
--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.

[RobG]

On Jan 29, 1:08*pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

RobG wrote:

The amount of memory consumed in either case is trivial, I think the
performance gain (again, it's very small in one-of cases) outweighs
the memory consumed.

I don't know what you mean by "one-of cases"

Single cases where extend() is called once or only a few times.

>, but my benchmarks show that
the performance gain is negligible, too. *With 10'000 iterations, it's again of

*30 ms in Firefox 2.0.0.11,

[...]

Yes, it's more a feel-good measure than a must-have. But if extend()
is to be used as a library function, why not optimise it? Anyhow,
it's up to individuals to chose how it's implemented, I just thought
it worth while posting an alternative.
--
Rob

[ron.h.hall]

On Jan 28, 1:03*pm, RobG <[e-mail]:

[...]

Richard Cornford suggested that can be written more efficiently by
reusing the Dummy constructor:

var extend = (function(){
* * function Dummy(){}
* * return (function(P){
* * * * Dummy.prototype = P;
* * * * return new Dummy();
* * });

})();

That could depend on how efficient one finds closures versus function
creation to be. Nonetheless, an "extend" function can be invoked
without use of closures or function creation. E.g.,

Object.prototype.
extend = function ( f )
{
if ( f !== null ) {
var
o = new arguments.callee( ( arguments.callee.prototype = this )
&& null )
;
return ( f && f.apply( o, [].slice.call( arguments, 1 ) ) ), o;
}
}
;

Moreover, ofen functionality trumps efficiency. Ignoring issues
related to Object.prototype, the above includes additional facility of
an extended object tailoring function and parameters, optionally
provided. In this form there is an intuitive inversion of the
Javascript paradigm, where the object being extended now has
precedence over the "new object" tailoring function.

../rh

[Joost Diepenmaat]

kj <so***@987jk.com.invalidwrites:

My book (Flanagan's javascript: The Definitive Guide, 5th ed.)
implies on page 111 that the following two constructs are equivalent:

( x.constructor == Foo )

and

( x instanceof Foo )

The author states that the instanceof operator computes its result
by examining the value of its first argument's the constructor
property.

However, I've recently ran into a situation that contradicts this.

I had some free time this weekend to do a somewhat extensive write-up
about this problem. It may be of interested to some people.

http://joost.zeekat.nl/constructors-...confusing.html

Feel free to ask questions or comment if it seems wrong or
incomprehensible.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[Joost Diepenmaat]

Thomas 'PointedEars' Lahn <Po*********@web.dewrites:

You should remove the entire footnote as it is pure nonsense.

You don't expect me to do anything based on that, do you? There is a
point to the foot note. I don't really care if you don't like it. If you
have any reasoned suggestions to improve it, (or even if you have good
reasons to delete it) I'd be more than happy to consider them.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[Joost Diepenmaat]

Thomas 'PointedEars' Lahn <Po*********@web.dewrites:

I won't even begin with denying every point that you wrote and provide
a valid reason for it. The reasons are at least in the specification.

As far as I can see the note is correct with regards to the spec. I'm
fine with you not providing a correction.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[John G Harris]

On Fri, 15 Feb 2008 at 22:38:45, in comp.lang.javascript, Joost
Diepenmaat wrote:

>John G Harris <jo**@nospam.demon.co.ukwrites:

>I don't understand why you don't like constructors. In Java and similar
languages the compiler writes part of the constructor's code. The
compiler makes sure that the constructor creates and initialises the
instance's ancestor properties.

It's not that I don't like constructors, it's that I don't like that I
/have/ to use them, when I usually can't use them for actually
initializing the objects correctly, so I end up with a load of empty
constructors. They just seem like more or less useless fluff that could
have been avoided by just providing direct access to the prototype.

<snip>

I'm puzzled. The work of building your new object will obviously be
packaged in a function, either for tidiness or because you believe in
encapsulation. How do you describe this function : a user-constructor,
an outer-constructor? It has to be something like that. I'm puzzled
because I can't see which part of that work couldn't be put inside the
javascript constructor.

I'm also puzzled by your reference to 'the prototype'. Which meaning of
the word 'prototype' are you using?

>Again, this is javascript, where you have to do it yourself. One obvious
way is to build a prototype chain with a layer of methods attached to
each prototype object. Each object in the chain has to be constructed of
course. The obvious way to do this is to have a constructor for that
particular kind of prototype. (Why are people so frightened of doing
this?)

Something is not quite as straightforward here as you make it seem. I'll
have to think about this and try some stuff.

<snip>

My web site has an example of what I'm thinking here :

<URL:http://www.jgharris.demon.co.uk/jsfeats/JSfeats.html#seca1p1>

It's very straightforward. It's also very tedious :-(
John
--
John Harris

[Joost Diepenmaat]

John G Harris <jo**@nospam.demon.co.ukwrites:

On Fri, 15 Feb 2008 at 22:38:45, in comp.lang.javascript, Joost
Diepenmaat wrote:

>>John G Harris <jo**@nospam.demon.co.ukwrites:

I'm puzzled. The work of building your new object will obviously be
packaged in a function, either for tidiness or because you believe in
encapsulation. How do you describe this function : a user-constructor,
an outer-constructor? It has to be something like that. I'm puzzled
because I can't see which part of that work couldn't be put inside the
javascript constructor.

The objects will be created in a function, yes. But when you're using
prototypes to inherit behaviour, you often can't use the super-object's
constructors to initialize instance properties since that would set the
properties of the prototype instead. What you then end up with is an
empty constructor with a .prototype that takes care of the shared
properties (usually just the methods, possibly some default
values). Plus a function (or method) to set the properties of the
instance that can be called when you're instantiating the sub object.

I'm also puzzled by your reference to 'the prototype'. Which meaning of
the word 'prototype' are you using?

The internal [[prototype]].

>>Again, this is javascript, where you have to do it yourself. One obvious
way is to build a prototype chain with a layer of methods attached to
each prototype object. Each object in the chain has to be constructed of
course. The obvious way to do this is to have a constructor for that
particular kind of prototype. (Why are people so frightened of doing
this?)

Something is not quite as straightforward here as you make it seem. I'll
have to think about this and try some stuff.

<snip>

My web site has an example of what I'm thinking here :

<URL:http://www.jgharris.demon.co.uk/jsfeats/JSfeats.html#seca1p1>

It's very straightforward. It's also very tedious :-(

I see where my confusion was coming from. You're using twice as many
constructors as I do: one constructor to initialize the prototype and
another to initialize the instance, for each "type" of object. I
generally write the instance initializers as methods of the respecive
[[prototypes]] instead. I don't have anything lying around to show what
I mean right now...

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[Joost Diepenmaat]

I updated the foot note.

http://joost.zeekat.nl/constructors-...fusing.html#1_

If anyone still objects to its content, please let me know why.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[John G Harris]

On Mon, 18 Feb 2008 at 08:56:37, in comp.lang.javascript, Joost
Diepenmaat wrote:

<snip>

>Right. For most of the code where I use a prototype chain containing
more than one or two custom prototypes I've found that having the
constructor abstracted away completely (only using automatically
generated empty constructors) made the code a lot simpler to write. In
the end though, I think it's mostly a question of taste.

Yes. There are several ways of doing it.

Therefore, your web page should make it clear that your complaints about
javascript are aimed at your way of doing it. Other people have no need
to complain.

John
--
John Harris

[Joost Diepenmaat]

John G Harris <jo**@nospam.demon.co.ukwrites:

Yes. There are several ways of doing it.

Therefore, your web page should make it clear that your complaints about
javascript are aimed at your way of doing it. Other people have no need
to complain.

Why would I do that?

On that page I'm pointing out some potentially confusing things that can
happen with constructors. *You* may not find them confusing, but at
least some people would - they confused me when I first ran into them
and they confused the person who originally started this thread - so I
tried to explain what's happening as clearly and objectively as I could.

I do have some complaints about the whole constructor-prototype idea in
general and I have sketched out some ways that I like to work around
them, but none of that is on that page, or even site. Most of it in this
thread, which people can read for themselves.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[John G Harris]

On Mon, 18 Feb 2008 at 22:01:43, in comp.lang.javascript, Joost
Diepenmaat wrote:

>John G Harris <jo**@nospam.demon.co.ukwrites:

>Yes. There are several ways of doing it.

Therefore, your web page should make it clear that your complaints about
javascript are aimed at your way of doing it. Other people have no need
to complain.

Why would I do that?

On that page I'm pointing out some potentially confusing things that can
happen with constructors. *You* may not find them confusing, but at
least some people would - they confused me when I first ran into them
and they confused the person who originally started this thread - so I
tried to explain what's happening as clearly and objectively as I could.

I do have some complaints about the whole constructor-prototype idea in
general and I have sketched out some ways that I like to work around
them, but none of that is on that page, or even site. Most of it in this
thread, which people can read for themselves.

I'll just remind you of how you introduced us to that web page :

<quote>
Just to give you some examples of what can go wrong with the IMO nasty
"new constructor()" syntax:
</quote>

John
--
John Harris

[Joost Diepenmaat]

John G Harris <jo**@nospam.demon.co.ukwrites:

On Mon, 18 Feb 2008 at 22:01:43, in comp.lang.javascript, Joost
Diepenmaat wrote:

>>John G Harris <jo**@nospam.demon.co.ukwrites:

>>Yes. There are several ways of doing it.

Therefore, your web page should make it clear that your complaints about
javascript are aimed at your way of doing it. Other people have no need
to complain.

I'll just remind you of how you introduced us to that web page :

<quote>
Just to give you some examples of what can go wrong with the IMO nasty
"new constructor()" syntax:
</quote>

What part of IMO do you not understand?

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[Joost Diepenmaat]

Just FYI: the introduction to that page was at msg-id
<87************@zeekat.nl>, in this thread, about 8 hours earlier, you
may have missed it then:

"I had some free time this weekend to do a somewhat extensive write-up
about this problem. It may be of interested to some people.

http://joost.zeekat.nl/constructors-...confusing.html

Feel free to ask questions or comment if it seems wrong or
incomprehensible."

Note, the "this problem" refers to the OP of this thread.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/