On Mar 11, 2008, at 8:32 PM, Kris Zyp wrote: > I like it too. Any chance that by setting the attribute at the same > time of > setting the property value, we could resurrect the possibility of > setting > other attributes as well (with a single method): > > Object.prototype.__setPropertyWithAttributes__(name, value, dontEnum: > boolean, readOnly: boolean, dontDelete: boolean);
Only if you cannot change an existing properties attribute, or delete an existing property and create a new one with the same name. Those cases would have to fail. A false return is not a fail-stop condition, so an exception might be better. Mark probably has thoughts on this -- he referred to "defensive consistency" as defined in his thesis when we discussed the silence-is-deadly ES1-era handling of assignment to read-only properties, and the almost useless boolean result of the delete operator. > I wonder if readonly and dontdelete are other attributes where > there might > be benefits derived from trusted code (regular ES3/4) being able to > control, > and untrusted code (ses, caja) not being able to control. I can't > think of > what those benefits might be, maybe another question for Mark or > Doug to > think on. You can't implement JS in JS without something like this. Narcissus has almost exactly what you describe here, only SpiderMonkey js shells built with NARCISSUS=1: http://lxr.mozilla.org/mozilla/search?string=__defineProperty__ But this, as its name suggests, is unsafe: it will redefine a property, clobbering any existing attributes and value. And yeah, the lack of named parameters hurts call-site readability. /be _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
