Re: [sv-ec] RE: Mantis 2358 - isssue 168

From: Neil Korpusik <Neil.Korpusik_at_.....>
Date: Tue Apr 28 2009 - 11:30:13 PDT
Hi Arturo,

Gord posted that clarification in the proposal for Mantis 2724.

From:
    When using the super within new, super.new shall be the first statement executed in the constructor.
To:
    A super.new call shall be the first statement executed in the constructor.


Neil



On 04/27/09 23:23, Arturo Salz wrote:
> Dave,
> 
>  
> 
> We agree that the language is awkward and can be improved (no point in 
> beating a dead horseJ) but the intent I believe is clear – Wasn’t Gord 
> going to suggest some improved verbiage.
> 
>  
> 
>             Arturo
> 
>  
> 
> *From:* owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On Behalf Of 
> *Rich, Dave
> *Sent:* Monday, April 27, 2009 7:13 PM
> *To:* Mark Hartoog; Bresticker, Shalom; sv-ec@eda.org
> *Subject:* RE: [sv-ec] RE: Mantis 2358 - isssue 168
> 
>  
> 
> Mark,
> 
>  
> 
> What does “using the super”  mean?
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] 
> *On Behalf Of *Mark Hartoog
> *Sent:* Monday, April 27, 2009 4:08 PM
> *To:* Bresticker, Shalom; Mark Hartoog; sv-ec@eda.org
> *Subject:* [sv-ec] RE: Mantis 2358 - isssue 168
> 
>  
> 
> Shalom,
> 
>  
> 
> Section 8.14 says:
> 
>  
> 
> When using the *super *within *new*, *super*.*new *shall be the first 
> statement executed in the constructor. This
> 
> is because the superclass shall be initialized before the current class 
> and, if the user code does not provide an
> 
> initialization, the compiler shall insert a call to *super*.*new 
> *automatically.
> 
>  
> 
> I don’t see what is unclear about this.  It says that if the user 
> doesn’t have a call to super.new, it is automatically called.
> 
>  
> 
> If the super class constructor requires arguments, obviously the 
> compiler cannot insert a call automatically. Section 8.16 says:
> 
>  
> 
> If the initialization method of the superclass requires arguments, there 
> are two choices: to always supply the
> 
> same arguments or to use the *super *keyword.
> 
>  
> 
> I guess this does not say it is illegal not to do one of these choices.  
> I could see adding a sentence to say when the super class constructor 
> requires arguments, it is illegal to not specify them in one of the two 
> ways.
> 
>  
> 
> *From:* Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> *Sent:* Sunday, April 26, 2009 11:33 PM
> *To:* Mark Hartoog; sv-ec@eda.org
> *Subject:* RE: Mantis 2358 - isssue 168
> 
>  
> 
> Mark,
> 
>  
> 
> 2358 brings up a number of points that need clarification. This is just 
> one of them, and not even the point that was the main point of the 
> ballot comment.
> 
>  
> 
> I would change the wording of your proposal, but that is a secondary 
> issue. It still leaves ambiguous the following points from the Mantis, 
> for example:
> 
>  
> 
> LRM is unclear where a user-defined sub-class constructor automatically 
> calls super.new() if it does not contain such a call explicitly. The 
> answer is yes, but a statement such as "The default constructor first 
> calls its base class constructor" can be interpreted as saying that it 
> is true only for default sub-class constructors. In fact, one company 
> published an incorrect interpretation.
> 
> What happens if super.new() requires arguments, but they are not 
> specified in the extends statement, and the sub-class new() implicitly 
> calls super.new()? (Probably a compilation error.)
> 
> If the extends statement specifies the super.new arguments, e.g., class 
> EtherPacket extends Packet(5);, may a sub-class user-defined constructor 
> contain an explicit call to super.new()? If so, what is the syntax, with 
> or without arguments, super.new() or super.new(5)?
> 
> (Your proposal says that the last option would not be legal, but still 
> leaves ambiguous whether super.new is implicitly called in a 
> user-defined constructor, whether an explicit call to super.new is 
> legal, and what is the syntax if so.)
> 
>  
> 
> Regards,
> 
> Shalom
> 
> Shalom Bresticker
> Intel LAD DA
> Jerusalem, Israel
> +972  2 589 6582 (office)
> +972 54 721 1033 (cell)
> 
>  
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] 
> *On Behalf Of *Mark Hartoog
> *Sent:* Monday, April 27, 2009 4:18 AM
> *To:* sv-ec@eda.org
> *Subject:* [sv-ec] Mantis 2358 - isssue 168
> 
> I discussed this issue with Arturo. He feels that the situation in 
> Mantis 2358 should be an error.
> 
>  
> 
> I have added a proposal to 2358 to make it an error. The proposal is:
> 
>  
> 
> At the end of section 8.16, Chaining constructors, add the following 
> paragraph:
> 
>  
> 
> It shall be an error for a derived class to specify the arguments to the 
> base class constructor both when the class is extended and with a 
> *super.new*(...) call in the constructor.
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
> 
> ---------------------------------------------------------------------
> 
> Intel Israel (74) Limited
> 
>  
> 
> This e-mail and any attachments may contain confidential material for
> 
> the sole use of the intended recipient(s). Any review or distribution
> 
> by others is strictly prohibited. If you are not the intended
> 
> recipient, please contact the sender and delete all copies.
> 
> 
> -- 
> 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* <http://www.mailscanner.info/>, and is
> believed to be clean.
> 
> 
> -- 
> 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.
Received on Tue Apr 28 11:32:05 2009

This archive was generated by hypermail 2.1.8 : Tue Apr 28 2009 - 11:32:49 PDT