[Bug 12845] Disallow shadowing attributes

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

--- Comment #21 from Cameron McCormack <cam@mcc.id.au> 2011-06-08 02:35:54 UTC ---
(In reply to comment #20)
> 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?

No.

> 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?)

No, the document only gives requirements on what objects should look like at
startup.

> 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).

That sounds reasonable.  I think you are right though that this likely doesn't
warrant specifying.

> > 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?

It can make promises about the behaviour of certain Function objects when they
are called.

> 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.

Guaranteeing nothing seems a bit much.  I think there is plenty you can
guarantee.  If you have

  interface Node {
    readonly attribute Node? parentNode;
  };

and script does

  var f = Object.getOwnPropertyDescriptor(Node.prototype, "parentNode").get;
  Object.defineProperty(Node.prototype, "parentNode", { get: function() { } });

then it's not "all bets off"; the guarantee that calling 'f' on a Node object
returns the Node's parent should still hold.  The spec doesn't make guarantees
on what `myNode.parentNode` will do explicitly.

> 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.

Allow user script to modify prototype objects such that sub-interfaces have
incompatible behaviour, do you mean?  They can of course, but I'm not sure that
helps determine whether we want to allow or disallow specifications from doing
it.

> >      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.

Although I did recently outlaw sequences from being used as the type of an
attribute, since it has suboptimal behaviour when used in a natural way -- bug
12287 -- I'm inclined to agree with Allen in general here.  There are only a
few instances of this in HTML5 at the moment.  If we consider them to be
footguns, let's raise bugs on them (as Ms2ger has done).

-- 
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 02:35:57 UTC