8 ms·

Advanced objects in JavaScript

162 points by btipling 12y ago

jvickers 12y ago
Alternatives to getType and setType functions (while still not using getters and setters): Have a single polymorphic function called type: type() gets the type, type(value) sets the type. Have .get and .set functions, called like: get('type'), set('type', value).
- btipling 12y ago
  I like that idea, but with Proxy you don't have to write the functions any more, you could just define that one get on the handler you feed into Proxy and then in your code you can access via the . notation, like: var obj = new Proxy( {foo_: "bar"}, {get: function(target, name) { return target[name + "_"]; }); console.log(obj.foo); //logs "bar" Of course maybe you'd do something a little fancier than just return the value, like return null for property names with _ to prevent accessing private variables. I don't know what the performance of Proxy will be like, but it's an alternative to getters and setters and lets you have a fall through for things you haven't defined. What I'm really excited about is reactivity on objects for setting and getting without using functions. You could have your setter trigger events without forcing someone to use a set function like you have in Backbone. I think we'll see an entirely new set of model libraries because of these new ECMAScript 5 and 6 features.
  - jvickers 12y ago
    I'm not yet excited about these getters and setters and new features in the latest JavaScript. I've put a lot of time and effort into developing ECMAScript (JavaScript) 3 patterns that overcome various limitations, and have got accustomed to the idea of deploying ECMAScript 3. In terms of providing an API, getters and setters will be very useful. It will be good to have out-of-the-box JavaScript functionality that does not require extra code to use, like various methods I use to overcome the ECMAScript 3 limitations. Does anyone have an estimate for when ECMAScript 6 will be widely deployed across browsers, almost ubiquitous? I would say now it's safe to use SVG in many situations on the web that would not have been OK a few years ago, I'm curious about when the tipping point will be with ECMAScript 6. Anecdotally, recently my customers have been a lot less interested in supporting older versions of IE, and I have used SVG in a couple of situations, and that would not have been OK a few years back. I have not been closely following the developments of ECMAScript 6, it has seemed like it will be a while until it's widely deployed. The only things I have found practical use for are typed arrays, and I have been using them in node specific code rather than in code that I expect to run across browsers. Though I am interested in the latest developments in JavaScript, my focus will still be on what can be done with the JavaScript available in almost every browser. I am also interested in making use of getters and setters in my code but being able to compile it to ECMAScript 3, I may be able to do some relatively simple text replacement rather than having to parse and compile an abstract syntax tree.
    - jvickers 12y ago
      https://github.com/google/traceur-compiler/wiki/GettingStarted https://github.com/google/traceur-compiler/wiki/GettingStart...
    - kelmop 12y ago
      Do you have any examples of these patterns?
    - cpeterso 12y ago
      Kangax's ES6 Compatibility Table tracks the implementation status for many browsers, though Chrome's ES6 support is hidden behind a pref: chrome://flags/#enable-javascript-harmony http://kangax.github.io/compat-table/es6 http://kangax.github.io/compat-table/es6
  - wwweston 12y ago
    > with Proxy you don't have to write the functions any more, you could just define that one get on the handler you feed into Proxy Doable with "old" JS. Consider this function: function prop(name, gNs) { var _name = '_' + name, get = gNs && gNs.get, set = gNs && gNs.set, undef = function (v) { return typeof v == 'undefined'; }, if (get && set) return function (x) { return undef(x) ? get.call(this, this[_name]) : (this[_name] = set.call(this, x), this); } if (get && !set) return function (x) { return undef(x) ? get.call(this, this[_name]) : (this[_name] = x, this); } if (!get && set) return function (x) { return undef(x) ? this[_name] : (this[_name] = set.call(this, x), this); } return function (x) { return undef(x) ? this[_name] : (this[_name] = x, this); } } Pass `prop` (a) the name of a property you're defining getter/setter methods for and (b) an object with any custom getter/setter you might care to define (or neither, if you like), and it'll return a function that will act as both which you can assign to a prototype.
    - btipling 12y ago
      I like that, but you'd still have to call a function to get the properties though and this wouldn't prevent anyone from accessing those properties directly. Like: obj.setFoo("bar"); obj.getFoo(); obj.foo = "bad stuff"; //overwritten instead of obj.foo = "bar"; obj.foo; obj.foo_ //error, not allowed access
      - wwweston 12y ago
        True enough, and if privacy is a must have, my implementation is a non-starter. I tend towards the (somewhat unpopular and certain arguable) opinion that need for privacy via a runtime-enforced mechanism is overrated... give us developers using an API/library effective/well-documented methods that do what we need and warn us when we shouldn't touch something with a convention (like an underscore), and usually we're happy to leave the black box closed. It's usually when abstractions leak or implementations aren't complete that we're tempted to tinker across boundaries, and when that happens, the lack of a privacy enforcement mechanism may not be the real problem. (OTOH, they can indeed help keep some bad situations from getting worse, and when trusted code is mingling with untrusted in situations like web mashups, privacy-enforcement can be really helpful for security...)
yoran 12y ago
I once participated in a web security research project where we used ES6 Proxies to sandbox third-party scripts, basically controlling what DOM operations they're allowed to do in a whitelist. This is relevant when you include sketchy advertisement scripts or scripts you don't trust (e.g. "trusted" scripts but delivered through an untrusted CDN). By default, no operations were allowed and by whitelisting until there were no more errors, we managed to effectively completely sandbox jQuery, Google Maps and Google Analytics. None of these scripts were allowed to execute more operations than the ones exactly required for them to function. Proxies were an elegant way to intercept getters and setters on window, document, location, etc...
- kelmop 12y ago
  do you have any examples of this? this seems very interesting
- voltagex_ 12y ago
  Are you able to link to the research? It sounds like a native-JS version of NoScript, which is really interesting (apologies to the dead comment under me which asked something similar)
  - yoran 12y ago
    Yep, here's the paper: http://www.acsac.org/2012/openconf/modules/request.php?module=oc_program&action=summary.php&id=77 http://www.acsac.org/2012/openconf/modules/request.php?modul... It was presented at ACSAC 2012.
- TazeTSchnitzel 12y ago
  This is actually a large part of why ES5 added these things, to enable Caja and the like.
- Mc_Big_G 12y ago
  Reminds me of https://github.com/tildeio/oasis.js https://github.com/tildeio/oasis.js but not sure if it solves the same type of problem.
elwell 12y ago
CoffeeScript abstracts out a lot of of awkwardness of working with JS objects.
- yarrel 12y ago
  It does however concrete in a lot of awkwardness from working with compiling a static language into a dynamic one then running it.
  - lowboy 12y ago
    CoffeeScript is not a static language - unless I'm misinterpreting what you mean by "static". And the compilation is pretty light. The syntax is different, but for the most part the semantics are 1:1 with Javascript. Having said that, any compile-to-language is going to introduce problems that need to be solved. Source maps and short watch+compile times have basically eliminated any problems for me.
  - ocodo 12y ago
    You're perhaps thinking of TypeScript.
- vlunkr 12y ago
  Yes, I love classes in CS. It makes using the prototype system so simple
VeejayRampay 12y ago
Good thing that this is all coming to Javascript. But I can't help but think we're in bizarro land when the main language of the most ubiquitous medium of the 21st century is only getting all that rather basic stuff (at least by all the other languages' standards) in 2015 or something...
- btipling 12y ago
  I think the slow browser updates that existed prior to Chrome might have contributed to a lull in developing the language. Some of these features can't be fixed for old browsers with a polyfill, but now that updates are happening quicker and there's a lot of excitement around the language I hope we see more of these.
  - TD-Linux 12y ago
    I don't think there were ever any "slow updates" to Javascript, except maybe in the period of IE5/6 dominance to Firefox 1.0. In the Browser Wars, Microsoft and Netscape competed to add features as fast as possible. Firefox still has many additional features in its JS engine that aren't in ECMAScript (for each, coroutines). I'm more concerned about adding features without fully considering the consequences. When you add a feature to Javascript, it's there forever. Rushed feature dumps are how we end up with things like the Web Audio API.
    - btipling 12y ago
      True, the early period had a furious pace of updates. I guess I was referring to the era of ES6, that lasted a long time. I think Microsoft at one point actually said that IE6 was the final browser and they wouldn't release a new version. IE6 was amazing when it first came out, but it became a blight in the end that hurt more than it helped.
    - arcatek 12y ago
      That's why some features have been postponed from ES6 to ES7
- 12y ago
Excavator 12y ago
Small correction: Symbol¹ is available in Firefox since back in ~June and should arrive in Firefox Beta in ~10days. 1: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- evilpie 12y ago
  Sadly there are still some kinks to work out so it's going to stay on Nightly only. https://bugzilla.mozilla.org/show_bug.cgi?id=1041631 https://bugzilla.mozilla.org/show_bug.cgi?id=1041631
  - Excavator 12y ago
    So earliest Release date is sometime in February then. Not that bad of a delay at least. Thanks for the update.
- btipling 12y ago
  I wasn't aware that the Firefox nightly had Symbol, I will download Firefox nightly later and update the post, I should have Firefox nightly anyway. Thank you! Edit, tested and updated blog post. Thanks again.
wging 12y ago
> You can use Object.getOwnPropertyNames to get all the properties defined on an object. This might be a nice alternative to a for in loop. Careful. These have different behavior for own properties which are not enumerable. A for-in loop doesn't include them, but Object.getOwnPropertyNames does.
- TazeTSchnitzel 12y ago
  Right Object.keys(foo) is better.
  - btipling 12y ago
    And I also missed out on including this, thank you.
- btipling 12y ago
  Nice catch, I will update the blog post.
tomphoolery 12y ago
This is pretty cool, but something about the notation confused me. Say we have an object called "foo": var foo = {}; Is it really necessary to define properties on it with this notation? Object.defineProperty(foo, 'bar', { value: 'baz' }); Since foo itself is an Object, wouldn't it also have this method? Why can't I define a property on foo like this? foo.defineProperty('bar', { value: 'baz' });
- btipling 12y ago
  Regarding your first question, it isn't necessary to define properties with that notation at all. You could just do: foo.foo = "bar"; But then it would be writable and configurable. Object.defineProperty(foo, 'bar', { value: 'baz' }); This foo.foo cannot be deleted. It cannot be written to. So it's a little different. But really I was just demonstrating the use of Object.defineProperty in a non-verbose way. You can try this out yourself, I made a jsfiddle: http://jsfiddle.net/btipling/q1v3fn20/ http://jsfiddle.net/btipling/q1v3fn20/ Regarding your second question, defineProperty is a method on Object, not Object.prototype. "Instances" as you might call them only have direct access to methods found on their prototype chain. You can think of Object.defineProperty as a static method on Object if that helps. I wrote a post about "this" which includes some information about prototypes: http://bjorn.tipling.com/all-this http://bjorn.tipling.com/all-this You should probably first checkout the mdn documentation though: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Inheritance_and_the_prototype_chain https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...
bshimmin 12y ago
Articles like this, about up-and-coming features in JavaScript, usually make me think two things: 1) JavaScript is starting to become a "big" language, in terms of number of keywords and syntax; 2) While many of these things that JavaScript is (finally) gaining are things we're familiar with in other languages (and have empirically found to be useful), they often seem somewhat more unwieldy, fiddly, and complicated in JavaScript. As a handwavy example, Ruby generally has most of the stuff these sorts of articles describe, and it can be complicated at times, but usually (in my experience) only when you're trying to do something complicated anyway; in JavaScript, a lot of it looks quite complicated out of the box even when you're doing something that ought to be simple. There are many JavaScript developers out there, some with years of experience, who are confused about, say, `var Foo = function() {}` versus `function Foo() {}`, or the difference between `new Foo()` and `Object.create(Foo.prototype)`. To be honest, it slightly worries me that even more complexity is being added at this point.
- btipling 12y ago
  JavaScript has a lot of complexity and little gotchas. I often compare the simplicity of Go with JavaScript and wish JS were more like that, but I still find myself enjoying JavaScript. I hope that "use strict"; evolves to further limit the bad pit falls even experienced developers can get stuck in. Some of the new features like isPrototypeOf can replace the old behavior, like instanceof. I would hope that once browsers start supporting more of the new things we all migrate to using them, if they're implemented well.

162 points by btipling 12y ago

Alternatives to getType and setType functions (while still not using getters and setters): Have a single polymorphic function called type: type() gets the type, type(value) sets the type. Have .get and .set functions, called like: get('type'), set('type', value).

btipling 12y ago
I like that idea, but with Proxy you don't have to write the functions any more, you could just define that one get on the handler you feed into Proxy and then in your code you can access via the . notation, like: var obj = new Proxy( {foo_: "bar"}, {get: function(target, name) { return target[name + "_"]; }); console.log(obj.foo); //logs "bar" Of course maybe you'd do something a little fancier than just return the value, like return null for property names with _ to prevent accessing private variables. I don't know what the performance of Proxy will be like, but it's an alternative to getters and setters and lets you have a fall through for things you haven't defined. What I'm really excited about is reactivity on objects for setting and getting without using functions. You could have your setter trigger events without forcing someone to use a set function like you have in Backbone. I think we'll see an entirely new set of model libraries because of these new ECMAScript 5 and 6 features.
- jvickers 12y ago
  I'm not yet excited about these getters and setters and new features in the latest JavaScript. I've put a lot of time and effort into developing ECMAScript (JavaScript) 3 patterns that overcome various limitations, and have got accustomed to the idea of deploying ECMAScript 3. In terms of providing an API, getters and setters will be very useful. It will be good to have out-of-the-box JavaScript functionality that does not require extra code to use, like various methods I use to overcome the ECMAScript 3 limitations. Does anyone have an estimate for when ECMAScript 6 will be widely deployed across browsers, almost ubiquitous? I would say now it's safe to use SVG in many situations on the web that would not have been OK a few years ago, I'm curious about when the tipping point will be with ECMAScript 6. Anecdotally, recently my customers have been a lot less interested in supporting older versions of IE, and I have used SVG in a couple of situations, and that would not have been OK a few years back. I have not been closely following the developments of ECMAScript 6, it has seemed like it will be a while until it's widely deployed. The only things I have found practical use for are typed arrays, and I have been using them in node specific code rather than in code that I expect to run across browsers. Though I am interested in the latest developments in JavaScript, my focus will still be on what can be done with the JavaScript available in almost every browser. I am also interested in making use of getters and setters in my code but being able to compile it to ECMAScript 3, I may be able to do some relatively simple text replacement rather than having to parse and compile an abstract syntax tree.
  - jvickers 12y ago
    https://github.com/google/traceur-compiler/wiki/GettingStarted https://github.com/google/traceur-compiler/wiki/GettingStart...
  - kelmop 12y ago
    Do you have any examples of these patterns?
  - cpeterso 12y ago
    Kangax's ES6 Compatibility Table tracks the implementation status for many browsers, though Chrome's ES6 support is hidden behind a pref: chrome://flags/#enable-javascript-harmony http://kangax.github.io/compat-table/es6 http://kangax.github.io/compat-table/es6
- wwweston 12y ago
  > with Proxy you don't have to write the functions any more, you could just define that one get on the handler you feed into Proxy Doable with "old" JS. Consider this function: function prop(name, gNs) { var _name = '_' + name, get = gNs && gNs.get, set = gNs && gNs.set, undef = function (v) { return typeof v == 'undefined'; }, if (get && set) return function (x) { return undef(x) ? get.call(this, this[_name]) : (this[_name] = set.call(this, x), this); } if (get && !set) return function (x) { return undef(x) ? get.call(this, this[_name]) : (this[_name] = x, this); } if (!get && set) return function (x) { return undef(x) ? this[_name] : (this[_name] = set.call(this, x), this); } return function (x) { return undef(x) ? this[_name] : (this[_name] = x, this); } } Pass `prop` (a) the name of a property you're defining getter/setter methods for and (b) an object with any custom getter/setter you might care to define (or neither, if you like), and it'll return a function that will act as both which you can assign to a prototype.
  - btipling 12y ago
    I like that, but you'd still have to call a function to get the properties though and this wouldn't prevent anyone from accessing those properties directly. Like: obj.setFoo("bar"); obj.getFoo(); obj.foo = "bad stuff"; //overwritten instead of obj.foo = "bar"; obj.foo; obj.foo_ //error, not allowed access
    - wwweston 12y ago
      True enough, and if privacy is a must have, my implementation is a non-starter. I tend towards the (somewhat unpopular and certain arguable) opinion that need for privacy via a runtime-enforced mechanism is overrated... give us developers using an API/library effective/well-documented methods that do what we need and warn us when we shouldn't touch something with a convention (like an underscore), and usually we're happy to leave the black box closed. It's usually when abstractions leak or implementations aren't complete that we're tempted to tinker across boundaries, and when that happens, the lack of a privacy enforcement mechanism may not be the real problem. (OTOH, they can indeed help keep some bad situations from getting worse, and when trusted code is mingling with untrusted in situations like web mashups, privacy-enforcement can be really helpful for security...)

yoran 12y ago

I once participated in a web security research project where we used ES6 Proxies to sandbox third-party scripts, basically controlling what DOM operations they're allowed to do in a whitelist. This is relevant when you include sketchy advertisement scripts or scripts you don't trust (e.g. "trusted" scripts but delivered through an untrusted CDN). By default, no operations were allowed and by whitelisting until there were no more errors, we managed to effectively completely sandbox jQuery, Google Maps and Google Analytics. None of these scripts were allowed to execute more operations than the ones exactly required for them to function. Proxies were an elegant way to intercept getters and setters on window, document, location, etc...

kelmop 12y ago
do you have any examples of this? this seems very interesting
voltagex_ 12y ago
Are you able to link to the research? It sounds like a native-JS version of NoScript, which is really interesting (apologies to the dead comment under me which asked something similar)
- yoran 12y ago
  Yep, here's the paper: http://www.acsac.org/2012/openconf/modules/request.php?module=oc_program&action=summary.php&id=77 http://www.acsac.org/2012/openconf/modules/request.php?modul... It was presented at ACSAC 2012.
TazeTSchnitzel 12y ago
This is actually a large part of why ES5 added these things, to enable Caja and the like.
Mc_Big_G 12y ago
Reminds me of https://github.com/tildeio/oasis.js https://github.com/tildeio/oasis.js but not sure if it solves the same type of problem.

elwell 12y ago

CoffeeScript abstracts out a lot of of awkwardness of working with JS objects.

yarrel 12y ago
It does however concrete in a lot of awkwardness from working with compiling a static language into a dynamic one then running it.
- lowboy 12y ago
  CoffeeScript is not a static language - unless I'm misinterpreting what you mean by "static". And the compilation is pretty light. The syntax is different, but for the most part the semantics are 1:1 with Javascript. Having said that, any compile-to-language is going to introduce problems that need to be solved. Source maps and short watch+compile times have basically eliminated any problems for me.
- ocodo 12y ago
  You're perhaps thinking of TypeScript.
vlunkr 12y ago
Yes, I love classes in CS. It makes using the prototype system so simple

VeejayRampay 12y ago

Good thing that this is all coming to Javascript. But I can't help but think we're in bizarro land when the main language of the most ubiquitous medium of the 21st century is only getting all that rather basic stuff (at least by all the other languages' standards) in 2015 or something...

btipling 12y ago
I think the slow browser updates that existed prior to Chrome might have contributed to a lull in developing the language. Some of these features can't be fixed for old browsers with a polyfill, but now that updates are happening quicker and there's a lot of excitement around the language I hope we see more of these.
- TD-Linux 12y ago
  I don't think there were ever any "slow updates" to Javascript, except maybe in the period of IE5/6 dominance to Firefox 1.0. In the Browser Wars, Microsoft and Netscape competed to add features as fast as possible. Firefox still has many additional features in its JS engine that aren't in ECMAScript (for each, coroutines). I'm more concerned about adding features without fully considering the consequences. When you add a feature to Javascript, it's there forever. Rushed feature dumps are how we end up with things like the Web Audio API.
  - btipling 12y ago
    True, the early period had a furious pace of updates. I guess I was referring to the era of ES6, that lasted a long time. I think Microsoft at one point actually said that IE6 was the final browser and they wouldn't release a new version. IE6 was amazing when it first came out, but it became a blight in the end that hurt more than it helped.
  - arcatek 12y ago
    That's why some features have been postponed from ES6 to ES7
12y ago

Excavator 12y ago

Small correction: Symbol¹ is available in Firefox since back in ~June and should arrive in Firefox Beta in ~10days. 1: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

evilpie 12y ago
Sadly there are still some kinks to work out so it's going to stay on Nightly only. https://bugzilla.mozilla.org/show_bug.cgi?id=1041631 https://bugzilla.mozilla.org/show_bug.cgi?id=1041631
- Excavator 12y ago
  So earliest Release date is sometime in February then. Not that bad of a delay at least. Thanks for the update.
btipling 12y ago
I wasn't aware that the Firefox nightly had Symbol, I will download Firefox nightly later and update the post, I should have Firefox nightly anyway. Thank you! Edit, tested and updated blog post. Thanks again.

wging 12y ago

> You can use Object.getOwnPropertyNames to get all the properties defined on an object. This might be a nice alternative to a for in loop. Careful. These have different behavior for own properties which are not enumerable. A for-in loop doesn't include them, but Object.getOwnPropertyNames does.

TazeTSchnitzel 12y ago
Right Object.keys(foo) is better.
- btipling 12y ago
  And I also missed out on including this, thank you.
btipling 12y ago
Nice catch, I will update the blog post.

tomphoolery 12y ago

This is pretty cool, but something about the notation confused me. Say we have an object called "foo": var foo = {}; Is it really necessary to define properties on it with this notation? Object.defineProperty(foo, 'bar', { value: 'baz' }); Since foo itself is an Object, wouldn't it also have this method? Why can't I define a property on foo like this? foo.defineProperty('bar', { value: 'baz' });

btipling 12y ago
Regarding your first question, it isn't necessary to define properties with that notation at all. You could just do: foo.foo = "bar"; But then it would be writable and configurable. Object.defineProperty(foo, 'bar', { value: 'baz' }); This foo.foo cannot be deleted. It cannot be written to. So it's a little different. But really I was just demonstrating the use of Object.defineProperty in a non-verbose way. You can try this out yourself, I made a jsfiddle: http://jsfiddle.net/btipling/q1v3fn20/ http://jsfiddle.net/btipling/q1v3fn20/ Regarding your second question, defineProperty is a method on Object, not Object.prototype. "Instances" as you might call them only have direct access to methods found on their prototype chain. You can think of Object.defineProperty as a static method on Object if that helps. I wrote a post about "this" which includes some information about prototypes: http://bjorn.tipling.com/all-this http://bjorn.tipling.com/all-this You should probably first checkout the mdn documentation though: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Inheritance_and_the_prototype_chain https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...

bshimmin 12y ago

Articles like this, about up-and-coming features in JavaScript, usually make me think two things: 1) JavaScript is starting to become a "big" language, in terms of number of keywords and syntax; 2) While many of these things that JavaScript is (finally) gaining are things we're familiar with in other languages (and have empirically found to be useful), they often seem somewhat more unwieldy, fiddly, and complicated in JavaScript. As a handwavy example, Ruby generally has most of the stuff these sorts of articles describe, and it can be complicated at times, but usually (in my experience) only when you're trying to do something complicated anyway; in JavaScript, a lot of it looks quite complicated out of the box even when you're doing something that ought to be simple. There are many JavaScript developers out there, some with years of experience, who are confused about, say, `var Foo = function() {}` versus `function Foo() {}`, or the difference between `new Foo()` and `Object.create(Foo.prototype)`. To be honest, it slightly worries me that even more complexity is being added at this point.

btipling 12y ago
JavaScript has a lot of complexity and little gotchas. I often compare the simplicity of Go with JavaScript and wish JS were more like that, but I still find myself enjoying JavaScript. I hope that "use strict"; evolves to further limit the bad pit falls even experienced developers can get stuck in. Some of the new features like isPrototypeOf can replace the old behavior, like instanceof. I would hope that once browsers start supporting more of the new things we all migrate to using them, if they're implemented well.