10337 2010-08-09 22:31:30 +0000 add [Supplemental] support 2011-06-22 00:29:55 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified PC All RESOLVED FIXED P2 normal --- 1 ian cam jonas mike public-webapps public-webapps-bugzilla oldest_to_newest 37323 0 ian 2010-08-09 22:31:30 +0000 For specification process reasons, some interface definitions don't get organised the same way as we want from implementations. I've assumed that [Supplemental] will exist, and used it as follows: - Setting [Supplemental, NoInterfaceObject] on an interface X with no ancestor and then saying: Y implements X; ...implies that the members in X are imported into Y as if the definition of Y always had X in it. - Setting [Supplemental, NoInterfaceObject] on an interface X that inherits from Y implies that there are objects called Y that have all the members of X and Y with X not appearing on the prototype chain. - Setting [Supplemental] on an interface that has the same name as an interface definition without [Supplemental]. The distinction between these cases is that I have three different cases where I need to do this. One is where I have some objects, e.g. Window, that are made up of APIs defined in other specs, and those APIs are also used by other interfaces. So I define Window, and then other specs slide stuff into Window, and slide stuff into other interfaces (like Worker- related ones). Another is WorkerGlobalScope, which I want to be the name of the interface implementing the global scope for workers, but there are two types of workers, and they have slightly different interfaces. And the third is the deprecated interfaces, where one interface, e.g. HTMLAnchorElement, is defined in two places. 49900 1 cam 2011-06-20 08:13:08 +0000 The first case doesn't need [Supplemental] any more. For the second case, I'd like a more descriptive name than [Supplemental]. I've used [CopyInheritedPrototype], but let me know if you think of something better. For the third case, I think using extended attributes for this isn't right; we need something in the core IDL syntax. I've added this syntax: interface HTMLAnchorElement : HTMLElement { // ... }; partial interface HTMLAnchorElement { // the attributes not fit for polite company }; 49904 2 jonas 2011-06-20 08:43:47 +0000 Could someone give an example of when the second case is desired? I.e. when it would be appropriate to use [CopyInheritedPrototype]? 49949 3 cam 2011-06-21 04:25:59 +0000 (In reply to comment #2) > Could someone give an example of when the second case is desired? I.e. when it > would be appropriate to use [CopyInheritedPrototype]? The case brought up in comment #0 is DedicatedWorkerGlobalScope/SharedWorkerGlobalScope. Maybe Ian can explain why regular inheritance doesn't work in that case. 49970 4 jonas 2011-06-21 06:21:54 +0000 It seems to me that for worker global scopes you want different interface objects for DedicatedWorkerGlobalScope and SharedWorkerGlobalScope. That way people can test what type of object they have and use it appropriately. 50081 5 cam 2011-06-21 23:26:56 +0000 (In reply to comment #4) > It seems to me that for worker global scopes you want different interface > objects for DedicatedWorkerGlobalScope and SharedWorkerGlobalScope. That way > people can test what type of object they have and use it appropriately. If HTML says [CopyInheritedPrototype] interface DedicatedWorkerGlobalScope : Window { ... }; then you do get an interface object "DedicatedWorkerGlobalScope" that you can test on. It's just that Object.getPrototypeOf(<global>) == Object.prototype, and there will be properties like DedicatedWorkerGlobalScope.prototype.open, etc. `<global> instanceof Window` will be false, though. 50091 6 jonas 2011-06-22 00:29:55 +0000 With "test on" I mean being able to do |foo instanceof DedicatedWorkerGlobalScope| which appears wouldn't be possible. I still don't understand why you would want to use CopyInheritedPrototype? Can you give any concrete use cases? And worst case, couldn't you just use "DedicatedWorkerGlobalScope implements Window" to accomplish the same API? Given that mixins is something that should be avoided if possible (since they fit poorly with JavaScript's single inheritance prototype chain), having multiple syntaxes to express them seems backwards.