[Bug 12845] Disallow shadowing attributes

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12845

--- Comment #20 from Allen Wirfs-Brock <allen@wirfs-brock.com> 2011-06-08 01:06:07 UTC ---
(In reply to comment #19)

> 
> Whether the implementation has an independent implementation of the get
> behaviour or whether it defers to the super-interface's getter does sound like
> an implementation decision.  But one thing that is visible to scripts is
> whether the actual getter on the two properties' descriptors are the same
> Function object or not.  Web IDL doesn't say currently whether these Function
> objects need to be distinct objects or not.

In general, do you every say where you have the same or different function
objects.  For example, if two different kinds of objects a and b both implement
the method foo specified by interface Bar do you require that a.foo === b.foo?
What about on the same object at different points in time (could an
implementation start out with a placeholder version of method and then replace
it upon first invocation?)

>From an implementation perspective this would probably be best left
unspecified.  But if you feel you must specify something then it should be that
that every function occurrence is different (it's easy to make to uses of the
same function appear different (wrapper one).  It's harder to make to different
functions appear the same).

> 
> The more general issue, whether overriding with different behaviour should be
> allowed by Web IDL or not, I'm still unsure about. The problem is with
> *incompatible* behaviour, right?  Different behaviour is OK, as long as it is
> consistent with the promises made by the definition of the super-interface. 
> The difference between "different" and "incompatible" behaviour isn't one we
> can check for in the IDL.  If we think that "different but compatible"
> behaviour will never come up when designing Web APIs, then we can get a small
> win by disallowing overriding in general (apart from the
> readonly-becoming-writable issue).  

Can WebIDL really make any promises about what happens after user code starts
changing things?  WebIDL can define the initial state of the Web interface
objects but if an implementation allows user code to changing or replacing
methods of these object then nothing can really be guaranteed after that point.
Since browser implementations already allow this (and I don't think anybody is
seriously proposing disallowing it) it seem pointless to try to forbid it now.


>      OTOH, we could just file bugs on the
> specifications that specify incompatible behaviour on sub-interfaces as we find
> them...

This seem like the right approach.  Don't write buggy,internally inconsistent
specifications and when you find one fix it.  Nothing you say in a
meta-specification is going to stop people from making mistakes or creating
poor designs.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Wednesday, 8 June 2011 01:06:14 UTC