- From: Justin Rogers <justrog@microsoft.com>
- Date: Sat, 6 Jun 2015 06:01:54 +0000
- To: Boris Zbarsky <bzbarsky@mit.edu>
- CC: Ilya Grigorik <igrigorik@google.com>, Jonas Sicking <jonas@sicking.cc>, "public-web-perf@w3.org" <public-web-perf@w3.org>, Przemysław Pietrzkiewicz <ppi@google.com>
Wow that is way better than my points. Taken one step further we implement our getters as functions. So the incumbent would always be the internal getter. I don't think we have any way to get the containing function other than a stack walk. > On Jun 5, 2015, at 10:46 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > >> On 6/6/15 1:33 AM, Boris Zbarsky wrote: >> Making workerStart just look at the time origin of the global the worker >> instance is associated with does not satisfy the comments in that code. >> Maybe that's OK, of course. I'm just saying if we _do_ want that >> property then we should use the incumbent settings object. > > One thing I should note, in the interests of full disclosure: if workerStart examines the incumbent settings object, then any attempt to hook it by getting the default getter and then defining the property to have a getter that does some other work (e.g. logs) and then calls the default getter will change the behavior, because then it will suddenly start returning a value that is always relative to the time origin of the global of the interposed getter. And that interposed getter won't be able to convert it to its caller's time origin, since there's no way to get hold of that in script... > > -Boris >
Received on Saturday, 6 June 2015 06:02:23 UTC