Subject: Re: [sv-ec] Meeting logistics (19 February) and future.
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Wed Feb 12 2003 - 14:19:37 PST
"David W. Smith" wrote:
> ...The focus on this meeting will be to finish the review of chapters 11 and 12. In order to facilitate this I request that ALL issues that are to be addressed in this meeting be sent to the reflector by Friday of this week. I have summarized all of the issues raised for Chapter 11, have taken care of all of the typographically related comments, and have collected responses for the rest. This summary will be sent out today or tommorrow. None of the topics in their will be raised in the meeting unless someone takes exception to the responses. What this means is that completing the review for Chapter 11 should be very quick.
Here's my comments on the rest of 11:
11.12: Still see no need for the final sentence.
11.13: The "note:" about "super.new" points out a flaw in the syntax. C++ syntax puts parent constructor
calls in the constructor declaration:
#include <stdio.h>
class foo { public: int a;
foo() {a = 2;}};
class bar : public foo { public:
bar() : foo () { a *= a;}};
main() {bar b; printf("%d\n",b.a);} // prints 4
I would suggest using the C++ syntax instead - which makes "super" unnecessary as a keyword
(if you use '::' as well).
11.14: $cast - What's this for? Isn't static checking sufficient, and it doesn't look user-replacebale to me.
11.15: See 11.13
11.16: The statement that local variables don't get inherited appears incorrect if you can access them
through superclass methods.
11.17: It's unnecessarily difficult to check the "only written once" rule for instance constants, it should
be relaxed to "can only be written to in the constructor(s)".
11.18: It's not clear to me what you gain by having a "virtual class", C++ lets you define virtual methods
as being null for either a superclass or a subclass, it's only an error if you try to use such a
method, that allows subclasses to implement subsets of functionality without having to create a
bunch of dummy methods (maybe with assertions in them). I'd suggest not using "virtual class"
and allowing '= null' as an alternative to the method body.
11.19: This appears to be only informative - is it necessary?
11.20: First paragraph seems inappropriate for an LRM. It also introduces the '::' operator - which
I find preferable to "super".
11.21: Can you use name binding for class template parameters?
11.22: Seems odd syntax - a by-product of using class...endclass rather than class..{..}
where you can just skip the {...} for the forward declaration. Too many touch-typers :-)
11.23: Still think a class without methods should be the same as a struct with syntax and semantics
to match, doing anything else will be expensive to fix later (I await Jay's comments). I will
strongly disagree with statement (4) until structs, classes, modules and interfaces are capable
of cross inheritance.
11.24: "shoot themselves in the foot" seems inappropriate (if accurate). The section appears to
be informative rather than something required in the LRM, maybe a description of the
implementation requirements would be better - when do objects get destroyed exactly?
If I pass a reference to an object inside another object does the system keep a copy of
the outer object or just the inner object until the reference disappears?
Regards,
Kev.
--- National Semiconductor, Tel: (408) 721 3251 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Wed Feb 12 2003 - 14:20:02 PST