[Bug 29574] Default visibility of accepted components

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29574

--- Comment #11 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
(In reply to Michael Kay from comment #9)
> (Terminology problems here: Is the component absent, or is its visibility
> absent? Or is its visibility present with a value of "absent"?)
I'd say the component is absent. We chose visibility="absent" to express that
and at the time found that a good resolution.

(In reply to Michael Kay from comment #9)
> I think the answer here might be to try and merge visibility="absent" into
> visibility="hidden". I'll sleep on this...
I'd rather not as there's an important difference: and absent component is not
there at all, a hidden component is there ("has a body") but cannot be invoked.
Indeed, neither can be invoked, but the semantics and implications are
different.


(In reply to Michael Kay from comment #10)
> (i) accept C with visibility="abstract"
> (ii) accept C with visibility="absent" (see above)
> (iii) override C with a concrete implementation
> (iv) do nothing.
> 
> We need to decide what happens in case (iv). Previously this would be the
> same as case (i), but that's not consistent with downgrading components from
> public to private. The choice, I think, is between (ii) and a static error.
It's not a trivial decision to take. The advantage of leaving it "abstract" is
that, while kind-of public and not private, it automatically delegates
implementations down the line if R uses Q uses P, where P has an abstract
component, Q doesn't implement it, but R does.

But at the same time it seems inconsistent with "make everything private by
default".

I'm a bit torn between the two choices: the first is slightly inconsistent with
the new line but has a potential usability feat.

The second is more consistent (your option (ii)).

Also, the second option seems to be consistent with an earlier bug on the
matter where I believe we resolved the issue with unimplemented abstract
components as being "absent" by default.

All in all I lean towards (ii) for consistency and principal of least surprise. 

A note on the errors:
- If P has abstract component A
- If Q uses P but does not implement A (defaults to "absent")

I think it makes sense to make *any* reference to A from within Q a static
error. Visibility "absent" should be close to the same behavior as a function
that is not available in the static context.

Not so for within P, because package P has visibility "abstract" so it can be
compiled with "virtual functions" and relegate the implementation.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 10 May 2016 01:07:58 UTC