Difference between revisions of "Refactor nsIDOMNavigator changes for pointer attribute to be in separate interface"
(Created page with 'When implementing the <code>navigator.pointer</code> [https://github.com/humphd/mozilla-central/blob/b9be545b1ab71aa12b337b63a1967bea1960f9af/dom/interfaces/base/nsIDOMNavigator.…') |
|||
Line 1: | Line 1: | ||
− | When implementing the <code>navigator.pointer</code> [https://github.com/humphd/mozilla-central/blob/b9be545b1ab71aa12b337b63a1967bea1960f9af/dom/interfaces/base/nsIDOMNavigator.idl#L63 change to nsIDOMNavigator.idl], I noticed that none of the other recent additions to navigator were included in the interface file (e.g., geolocation). Today I noticed that these are actually done in separate interfaces, which expose a single attribute. I assume this was done so as to not alter the UUID for the Navigator Interface, or so as to separate the original definition of Navigator without recent changes. | + | When implementing the <code>navigator.pointer</code> [https://github.com/humphd/mozilla-central/blob/b9be545b1ab71aa12b337b63a1967bea1960f9af/dom/interfaces/base/nsIDOMNavigator.idl#L63 change to nsIDOMNavigator.idl], I noticed that none of the other recent additions to navigator were included in the interface file (e.g., geolocation). Today I noticed that these are actually done in separate interfaces, which expose a single attribute. I assume this was done so as to not alter the UUID for the Navigator Interface, or so as to separate the original definition of Navigator without recent changes. I asked dougt why he chose this method: |
<pre> | <pre> |
Revision as of 22:28, 16 November 2011
When implementing the navigator.pointer
change to nsIDOMNavigator.idl, I noticed that none of the other recent additions to navigator were included in the interface file (e.g., geolocation). Today I noticed that these are actually done in separate interfaces, which expose a single attribute. I assume this was done so as to not alter the UUID for the Navigator Interface, or so as to separate the original definition of Navigator without recent changes. I asked dougt why he chose this method:
20:31 < humph> dougt: question for you 20:32 < humph> what was the reason you extended Navigator using nsIDOMNavigator* (e.g., new interface with single properties) vs dropping on nsIDOMNavigator. Was it to not touch the uuid, or to leave the interface unaltered or ? 20:33 < dougt> humph: its the COM way of doing things. 20:34 < dougt> but, in reality, you could do either 20:34 < dougt> i do not know of anyone looking for a specific uuid 20:34 < roc> these days we just extend the main interface 20:34 < dougt> they usually get the navigator object off of window. 20:34 < roc> we're reducing the number of interfaces 20:34 < dougt> roc: that is good 20:34 < dougt> it does break anyone looking for a specific id 20:34 < dougt> but, i don't think we should support that if it means cost 20:35 < dougt> humph: you should ask jst what he wants to do. 20:35 < khuey> well, you use separate interfaces if you want it to be preffable 20:35 < dougt> that is one way. 20:35 < khuey> indexedDB works like that 20:36 < dougt> for dom/* we should just defer to JST unless we have data that it hurts doing it this way
TODO: connect with jst and figure out which way to go.