Le 26/12/2012 23:14, David Herman a écrit :
On Dec 24, 2012, at 2:34 PM, David Bruant <bruan...@gmail.com> wrote:
I've reading the loader API [1] and I was wondering if it was possible to
dynamically change the global. I think it is by doing the following, but tell
me if I'm wrong:
That wasn't the intention. It probably wasn't written out since the full
semantics isn't spelled out yet (though Sam and I have been making good
progress working through the details of the semantics), but the idea was that
the properties of the options object are read in up-front and stored
internally. The getter always returns that internally closed-over value that
was obtained when the loader was first created.
Ok, thanks for the clarification. The strawman as it was didn't explain
the full semantics hence my question.
In other words, in the global in the loader the initial or the dynamic value of the
"global" option?
The initial value. We can look into what it would mean to make it modifiable,
but we'd probably not make that the API; we'd probably just have a setter.
Good point.
[Adding MarkM into the mix for this part]
I wish to point out a potential security/convenience issue regarding
inherited getter/setters. My point is broader than the 'global' loader
situation (it includes everything covered by WebIDL for instance), but
let's assume a 'global' setter is added to Loader.prototype and I'll
draw the general conclusion from this example.
If I want to share a single loader instance to someone else, but not
provide access to the loader global, I have to delete
Loader.prototype.global (otherwise, someone can extract the getter and
use the reference to the loader instance to retrieve the global)
The problem with deleting Loader.prototype.global is that it's deleted
for every single instance which in turns make the code harder to write
(because, defensively, one needs to extract the getter/setter pair an
then use that instead of the more convenient "myLoader.global" syntax).
The opposite way, if freezing Loader.prototype, it becomes *impossible*
to revoke the capability to introspect instances using the inherited
getters/setters.
In essence, an inherited accessor means that the choice allowing access
to a given property isn't a per-instance choice anymore. It's a
per-"class" choice (keep it or remove it for every instance) which is
probably fine for most situations, but certainly too coarse for some others.
Since the amount of storage is equivalent anyway (you need some sort of
private property to associate the global to the loader instance), I
would suggest to go to an own "global" data property for loaders... and
I guess to stay away from inherited accessors when describing a
per-instance property for the reasons I described.
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
