RE: [sv-ec] 1356: a few comments

Changed "sub interface class" to "interface subclass".

I already changed "parameters" to "arguments". Otherwise, the whole thing is a bit ugly and needs some heavy re-wording. As I replied to Fransios' comments on the same section, the idea is just that if two method prototypes are too different, it isn't possible to write a single method implementation that can satisfy the requirements for both interface method prototypes simultaneously (but that wording isn't too good either).

-Brandon

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Jonathan Bromley
Sent: Monday, August 29, 2011 8:58 AM
To: sv-ec@eda.org
Subject: [sv-ec] 1356: a few comments

I have tried to do a careful review of the latest proposal (rev.10) for
1356.

It's now very clear, and it answered all the questions that came to mind
as I read it.

However, I found a couple of issues with the text. They're both about
precision of language rather than any technical concern.

In the second paragraph of 8.25.2, about 60% down page 3, we find "the
sub interface class aggregates interface class members". This is very
hard to parse, and although I guess we all know what's meant by "sub
interface class" it doesn't seem to be a very precise term. Could we
consider "interface subclass", or "extended interface class", or somesuch?

In 8.25.6.1, the last plain-text sentence on page 7 ("If the parameters
and/or return types...") looks very strange. I think "parameters"
should be "arguments". And surely it isn't only about type
(in)compatibility of arguments and return; rather, the methods must have
compatible signatures (although I don't know whether that's explicitly
defined anywhere in the LRM). In particular, the notion of "compatible
signatures" says a bunch of stuff about task vs. function, existence of
default arguments and so on - not merely "compatibility" of types.

Otherwise it all seems very mature and thorough.

Thanks

Jonathan Bromley

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.