RE: About window.performance namespace

Hi Jonas, 

You've pointed out a valid theoretical coding pattern that would potentially have compatibility issues. Through the research tools that we have collectively in this working group, we found that all of the patterns involving the performance namespace used the initial declaration: var performance.

Using different namespaces like "pagePerformance" or "performanceMetrics" does not eliminate the problem altogether. We have decided to continue to use the performance namespace as it is suitable and intuitive for developers when this working group adds additional attributes / metrics.

Thus, to mitigate the compatibility problem we've also decided to make the namespace itself replaceable. 

Anderson Quach
IE Program Manager

-----Original Message-----
From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Jonas Sicking
Sent: Wednesday, January 05, 2011 12:19 AM
To: Zhiheng Wang
Cc: Sigbjørn Vik; public-web-perf
Subject: Re: About window.performance namespace

Note that just making it replaceable doesn't help code like:

if (!performance) {
  ... lazy-initialization code here ...
}
codeUsingPerformance();

or

if (...someTests...) {
  performance = true;
}

... much later ...
if (performance) {

}

I haven't really followed the discussions here, but is there a reason the property couldn't be named something with a smaller risk of collisions, such as "pagePerformance" or "performanceMetrics"?

/ Jonas

On Tue, Jan 4, 2011 at 11:56 PM, Zhiheng Wang <zhihengw@google.com> wrote:
>    Greetings!
>
>    Yes, those determined enough would still be able to swap out the 
> timing object. It's not ideal but rather some compromise to avoid 
> breaking existing codes using the window.performance object. Though, 
> it still makes sense to me to have underneath attributes read-only as 
> they are properties of the page/navigation.
>
>    It will be great if you can join us at this week's conf call to 
> chat more on this.
>
> cheers,
> Zhiheng
>
> On Tue, Dec 21, 2010 at 12:22 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote:
>>
>> On Tue, 21 Dec 2010 01:11:41 +0100, Zhiheng Wang 
>> <zhihengw@google.com>
>> wrote:
>>
>>>> On the other hand, I see valid use cases for overwriting the 
>>>> sub-objects.
>>>> For instance in my debug environment, I know one of the attributes 
>>>> is way off, so I want to change/overwrite that, in order to see the 
>>>> correct output from the third party timing script.
>>>>
>>>
>>>    Instead of changing/overwriting individual attributes, you can 
>>> create a mock performance object and swap out window.performance in 
>>> the debugging environment.
>>> It takes some extra work but testing/debugging probably worth it. 
>>> :-)
>>
>> But in this case, the attributes on the performance object are 
>> trivially
>> replaceable:
>>
>> var perf2 = window.performance;
>> perf2.timing = new Object();
>> window.performance = perf2;[1]
>>
>> If this can be done this easily, I am not certain I see the benefit 
>> of making window.performance.timing read-only in the first place?
>>
>> [1]
>> Or a more roundabout way, in the case the read-only attribute would 
>> be copied across on the first line above:
>> var perf2 = new Object();
>> for (attr in window.performance) {
>>        if (attr != "timing") perf2[attr] = window.performance[attr]; 
>> } perf2.timing = new Object(); window.performance = perf2;
>>
>> --
>> Sigbjørn Vik
>> Quality Assurance
>> Opera Software
>>
>
>

Received on Wednesday, 5 January 2011 17:08:58 UTC