modisposition

I am talking about enumerable , configurable , and writable properties of a generic property descriptor. enumerable most likely the only one we all expect: if false, a classic for/in loop will not expose the property, otherwise it will. enumerable is false by default. writable just a bit more tricky than we think. Nowadays, if a property is defined as non writable, no error will occur the moment we'll try to change this property: var o = {}; Object.defineProperty(o, "test", { writable: false, value: 123 }); o.test; // 123 o.test = 456; // no error at all o.test; // 123 So the property is not writable but nothing happens unless we try to redefine that property. Object.defineProperty(o, "test", { writable: false, value: 456 }); // throws // Attempting to change value of a readonly property. Got it ? Every time we would like to set a property of an unknown object, or one shared in an environment we don't trust, either we use a try/catch plus double ...

Update Yes, I did it: getters and setters for IE < 9 and other browsers After my early Hooorrayyyy! about compatible IE , I have been experimenting a bit more on how to solve the JSObject to VBVariant and vice-versa assignment and the result was an horrendous monster loads of potential memory leaks and performances implications for the already slow bounce of browsers such IE8, 7, and 6. Since limitations were also too many, as described in this even earlier attempt from dojo framework , I have realized that VBScript was simply a no-go , or better, probably the wrong answer to the question: how can I have cross-browser getters and setters? The jQuery Hybrid Answer Back in 2009, James Padolsey described the jQuery framework as a sort of getters/setters simulator API, comparing the semantic and beauty of non-standard Spidermonkey __defineGetter__ and __defineSetter__ , against jQuery coding style, where many "methods" could be considered as getters or setters. // get t...

In my precedent post entitled A Pascal record via JavaScript I have showed a basic function able to emulate type hints behavior via JavaScript. Even if that was a proof of concept, I consider other languages simulation of unsupported features an error, first of all because the behavior will rarely be exactly the expected one, secondly because our curent programming language may already have something similar to better learn and use. A new ES5( direction ) As soon as I have written the Pascal example, I have realized that the good "old" Object.defineProperty , implemented in all major browsers (IE The only missing part, intrinsic in the JavaScript nature, is the property type, where this type could be eventually used for arguments or returns checks when the property is a method. My Early Attempts Back in May 2007, my JavaStrict experiment was already trying to do something similar, something implemented after 2 years even in dojo framework as well. This may tell us that ...

Just a quick post about some clever hack we should probably forget ... make old scripts less obtrusive using new ES5 features. I am talking bout those guys out there that use scripts with a classic: onload = function () { ... }; // or this.onload = ... // or window.onload ... // or self.onload ... // etc etc Apparently WebKit Nightly fires an error when we try to define getters and setters via Object.defineProperty and this is already enough to remove that "hoooraayyyy" for my silly test .... here the code: Object.defineProperty(this, "onload", (function (self, callback) { function onload(e) { while (callback.length) { callback.shift().call(self, e); } } self.addEventListener ? self.addEventListener("load", onload, false) : self.attachEvent("onload", onload) ; return { get: function () { return onload; }, set: function (onload) { callba...

In my latest posts I have talked about current situation for JavaScript " Classes ". In Good Old And Common JS Errors I have introduced a misconception of a generic "Class" function which is usually not able to produce instanceof Class , considering Classes in JS are functions indeed. In Better JS Classes I have explained how to write a meaningful Class factory , avoiding the _super pollution over each extended method, while in the JS _super Bullshit I have explained why the _super/parent concept does not scale with JavaScript prototypal inheritance model. More than a dev, Mr Crockford included, agreed that in JavaScript the classical pattern does not fit/scale/produce expected results, and even worst, it could cause "disasters" during a session and slow down overall performances (and about this topic I have already said that web developers should stop to test their stuff with powerful CPU, read Macs! Buy a bloody Atom based device as I have done and af...

I do not want to spend a single word about Internet Explorer 8 Object.defineProperty implementation, which works only with DOM prototypes and the super global window but not with user defined objects , as __defineGetter__ and __defineSetter__ do since ages : Standards are an important factor to ensure browser interoperability for the Web developer (n.d. oh, really?!??!?!!!!) . The accessor property syntax has only recently begun standardization (you guys have a weird concept of the time ... or the meaning of "recent" in IT therms ...) . As such, many browsers support an older, legacy syntax ... (n.d. which at least has dignity to work with every kind of object ... ) Anyway, few things are better than nothing, so welcome to Object.defineProperty! Let IE8 behaves like every other or change every other to respect new M$ standard? This was the first question when I thought about this new global function: does it mean we finally have a way to emulate __defineGetter__ and setter in...