Dynamically changing of loader global

David Bruant bruant.d at gmail.com
Wed Dec 26 15:03:05 PST 2012

Le 26/12/2012 23:14, David Herman a écrit :
> On Dec 24, 2012, at 2:34 PM, David Bruant <bruant.d at 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 

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.


More information about the es-discuss mailing list