Comments on: Getters and Setters in JavaScript

By: Victor Nazarov

Victor Nazarov — Fri, 13 Jul 2007 21:01:35 +0000

>Constructor.prototype = {
>publicList: [],
>
>get publicLength () {
>return this.publicList.length
>}
>}

I think, that better don’t write getters like this. May be it works, but code is smelling…

By: Modular Homes

Modular Homes — Tue, 12 Jun 2007 14:01:57 +0000

Find a modular homes builder to construct your dream home.

By: Daniel Higginbotham

Daniel Higginbotham — Mon, 18 Dec 2006 20:30:45 +0000

Is there any way to test whether a method is a getter or setter?

By: atleta

atleta — Wed, 30 Nov -0001 00:00:00 +0000

Yep… this is an almost exact copy from the devmo (mozilla developer) JS documentation. What I can’t find there however is how do you define getters and setters in a constructor function (or using the .prototype form)?

Because it’s quite rare (I think) to declare a concrete object out of the (or into the :) ) blue. But usually we create classes (i.e. multiple instances of the same object). But this form only works concrete object creation.

By: Johan SundstrÃ¶m

Johan SundstrÃ¶m — Wed, 30 Nov -0001 00:00:00 +0000

This may come out a bit harsh, due in part to the late hour. I always find it a bit unfortunate when influential blogs mention powerful concepts like these, though, without a context of when or how they can be put to good use, rather than making code harder to read, understand and debug, or less portable, as is the case in these two examples.

First, by changing the expected results of a few very basic lines of code that surface wise seem not to do any destructive changes on a, then by changing the semantics of base language parts, which serves to make your code blend worse with code not invented here.

Used right, they are powerful tools that can be put to use to maintain backwards compatibility with archaic APIs you otherwise would have had to leave behind, for instance. – Without making those parts of the code added for the legacy support add much clutter to your code base, nonetheless.

By: Jun Yang

Jun Yang — Wed, 30 Nov -0001 00:00:00 +0000

Good pointer. I guess this is not supported in IE? I tried it with Rhino 1.6R2 and it is not supported there. Is this part of the standard BTW?

By: Scott McCoy

Scott McCoy — Wed, 30 Nov -0001 00:00:00 +0000

Last I checked, Microsoft’s JScript (or IE) ECMA implementation does not support setters and getters in any form.

During object construction, one of two approaches may be used, obviously since you can do this in the prototype exactly as the syntax above, since an object prototype is simply an object itself.

In order to provide lexical access to local data in a constructor itself (aka. private data), below is an example of both approaches:

function Constructor () {
var foo = []

this.length getter = function () {
return foo.length
}
}
Constructor.prototype = {
publicList: [],

get publicLength () {
return this.publicList.length
}
}

This way you can dynamically set the getter or setter of any property.

As far as being a part of a specification, this was originally extracted from the ESR4 proposal, which also adds a bunch of unneccesary crap…but this is one of the useful features it adds :-) It’s true that rhino should support this but it doesn’t, patches are welcome.

This web application could use some advanced formatting.