[sv-ec] RE: feedback on Mantis 1356

Leaving #5 and #10 open, #7 half open.

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Steven Sharp
Sent: Monday, August 29, 2011 8:51 AM
To: sv-ec@eda.org
Subject: [sv-ec] feedback on Mantis 1356

I am OK with the intent of the proposal, but the text needs more work. Here are some issues to start with.

1. In the syntax changes for 8.3, the semicolon is in the wrong place. It should be after the optional "implements" clause.
[Tipp, Brandon P] Looks like it was removed completely. Fixed.

2. At the start of the text for 8.25, the use of the word "introduces" makes no sense for the standard. The proposal introduces interface classes to SV, but after the text is part of the standard, what is SV introducing them to? SV can't introduce them to SV, and it can't be introducing them to the domain of programming languages, since the concept already existed there.
[Tipp, Brandon P] Stealing from the section on abstract classes, "A set of classes may be created that can be viewed as all having a common set of behaviors. This is characterized as an interface class."

3. In 8.25, saying that an interface class "is a requirement" is inaccurate. It is a type or perhaps a declaration. It creates those requirements, and they are its main purpose, but it isn't the requirement.
[Tipp, Brandon P] Already changed per Francios' feedback.

4. In 8.25, at the point where it says "The provided implementations shall", the reader has no idea what these provided implementations are. The text should first introduce the idea that there can be other class types that implement the interface class (though the exact way this is specified can wait). After the user knows that it is talking about some other class types, then they have a reference point to understand what those class types are required to do.
[Tipp, Brandon P] Again, changed per Francios' feedback

5. In 8.25, the third paragraph is disjointed. Adjacent sentences seem unrelated. It needs to be reorganized.
[Tipp, Brandon P] At this point, I need more specific feedback than this.

6. In 8.25.2, the sentence containing "aggregates" is difficult to parse. It takes rereading to figure out that "aggregates" is apparently being used as a verb here, since it is used as a noun everywhere else in the standard. Assuming that this is the intent, I would suggest another word that can't be read as a noun, such as "combines".
[Tipp, Brandon P] Already changed per Francios' feedback

7. In 8.25.3, saying that parameters and types are "implicitly static" seems confusing. Yes, they are static and this is implicit, but why say this? Usually when the standard talks about something implicit, it is in contrast to another form that is explicit. So when somebody sees text saying that these are implicitly static, the next thought is "and how do I override that explicitly?" It could also be taken as specifying something special about interface classes. The intent is just to point out the fact that these things are static as in any class, and can be referenced with a class scope qualifier, as in any class. This is not helped by the use of the term "interface class select", which sounds like it is introducing a new concept. Presumably the intent is to talk about a class member select that uses an interface class handle. This text is presumably trying to specify that these static things can be accessed via a class scope, as with any class, but cannot be referenced from an instance name as they can be in other classes (though these aren't constant expressions there).
[Tipp, Brandon P] Removed the word "implicitly". I don't know what to do about the "interface class select" part. SV-EC specifically said that they wanted access to parameters via the dot operator for interface classes should be illegal, despite the fact that it's legal for non-interface classes.

8. In 8.25.4, when talking about the restrictions on implementing or extending from parameters, it should specifically say "type parameters". Most readers probably think of value parameters first when they read the term parameter, which makes the sentence hard to understand until they reach something that makes it clear that it meant type parameters. Then they have to go back and reread it with that knowledge.
[Tipp, Brandon P] Already changed per Francios' feedback

9. In 8.25.4, talking about the "implemented" or "extended" class seems potentially confusing. I understand the intent, but the terminology has not been used previously, so it may not be obvious.
[Tipp, Brandon P] From Francios' feedback, it was changed to "implement" and "extend", but I'm not sure if this is better since it still doesn't match the keywords "implements" and "extends"

10. In 8.25.6, I don't like the description of merging/inheriting symbols. I don't think it is an accurate description of the process of resolving the names.
[Tipp, Brandon P] Changing the word "merged" to "inherited". Otherwise, I don't know how you want to re-word this. Anything more specific on what to change and how?

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.