Brendan Eich interview
Ben Crowell
http://www.sdtimes.com/blog/post/2009/04/16/Brendan-Eich-Explains-ECMAScript-Fifth-Edition-To-You.aspx
deals with ECMAScript 3.1.
Opinions?
Where could one look online for an explanation of what some of this
stuff actually is and how it would work (getters and setters, strict
mode, built-in JSON)?
Martin Honnen
> Where could one look online for an explanation of what some of this
> stuff actually is and how it would work (getters and setters, strict
> mode, built-in JSON)?
JSON:
https://developer.mozilla.org/En/Using_JSON_in_Firefox
http://msdn.microsoft.com/en-us/library/cc836458(VS.85).aspx
Mozilla's JavaScript implementation has had getters and setters for
quite a while
(https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Creating_New_Objects/Defining_Getters_and_Setters)
although I haven't checked whether that is the same syntax as in the
latest attempt to finally agree on a new ECMAScript edition.
IE 8 has getters/setters for DOM stuff
(http://msdn.microsoft.com/en-us/library/dd229916(VS.85).aspx) and that
article claims "Internet Explorer 8 is the first browser to adopt the
ECMAScript 3.1 syntax for defining accessor properties", again I have
not checked whether the syntax is the same as in the latest attempt to
agree on a new ECMAScript edition (where 3.1 has been pimped to 5).
--
Martin Honnen
http://msmvps.com/blogs/martin_honnen/
RobG
> Ben Crowell wrote:
> > Where could one look online for an explanation of what some of this
> > stuff actually is and how it would work (getters and setters, strict
> > mode, built-in JSON)?
>
>
> Mozilla's JavaScript implementation has had getters and setters for
> quite a while
> although I haven't checked whether that is the same syntax as in the
> latest attempt to finally agree on a new ECMAScript edition.
If they become widely implemented, will they just be another language
feature to abuse?
It might be convenient to have a getter where a value must be
calcuated, e.g element.getHeight() might become element.height, but
it also seems that things that really should look like methods may
become getters or setters that don't look like they are methods, e.g.
if you have an array-like object with a calcuated key for new
properties, e.g.
Current way (though I would probably use the module pattern to keep
prefix and lastIndex private):
var obj = {
prefix: 'key_',
lastIndex: 0,
getNewKey: function() {
this.lastIndex++;
return this.prefix + this.lastIndex;
}
}
// Get a key
var newKey = obj.getNewKey();
alert(newKey);
Using getter:
var obj = {
prefix: 'key_',
lastIndex: 0,
get newKey() {
this.lastIndex++;
return this.prefix + this.lastIndex;
}
}
// Get a key
var newKey1 = obj.newKey;
To me, the first is preferable as it is obvious that a function is
being called and therefore something is being calculated, even if
'get' is not included in the name, whereas in the second it is not.
It isn't clear that accessing newKey will neceesarily return a new
value each time or do any calculation (call a method) at all.
Anyhow, do getters and setters really add anything useful, or are they
just new ways to obfuscate code? Would it be better to allow programs
to set readOnly properties and hence force the use of a set function
at least?
>
> IE 8 has getters/setters for DOM stuff
> (http://msdn.microsoft.com/en-us/library/dd229916(VS.85).aspx) and that
> article claims "Internet Explorer 8 is the first browser to adopt the
> ECMAScript 3.1 syntax for defining accessor properties", again I have
> not checked whether the syntax is the same as in the latest attempt to
> agree on a new ECMAScript edition (where 3.1 has been pimped to 5).
I think that might be an incorrect use of "pimp", though I may not be
hip enough to US slang to know for sure. If they want to be cool, why
not be way ahead of the curve and call it "five-point-oh". :-)
--
Rob
kangax
> Anyhow, do getters and setters really add anything useful, or are they
I think your example is biased :) Take a look at something like this and
compare to how you would write it without getters/setters:
// using mozilla get/set extension
function makePoint(x, y) {
return {
get x() {
return x;
},
set x(value) {
if (typeof value == "number") {
x = value;
}
},
get y() {
return y;
},
set y(value) {
if (typeof value == 'number') {
y = value;
}
}
}
}
var p = makePoint(10,10);
p.x; // 10
p.x = 'a';
p.x; // 10
p.x = 20;
p.x; // 20
Of course, there's nothing wrong with getX(), setX() and getY(), setY(),
but why extra verbosity when plain property access/assignment is just as
descriptive (and, yet, encapsulates an additional logic, such as the one
here - ensuring a proper type before setting a property to a new value)
> just new ways to obfuscate code? Would it be better to allow programs
> to set readOnly properties and hence force the use of a set function
> at least?
Doesn't ES3.1 already allow to freeze/seal objects (i.e. manipulating
its [[Configurable]] and [[Writable]] properties)?
[...]
--
kangax