RE: [sv-ec] Definition of access for class parameters.

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Tue May 05 2009 - 10:47:47 PDT
Thanks.

Currently 2598 has its own proposal attached, and there is no note in 2598 or 2608 pointing to 2575.
There should also be a comment in one of the Mantis fields of 2575 listing the ballot comments it addresses.

Shalom
 

> -----Original Message-----
> From: Francoise Martinolle [mailto:fm@cadence.com] 
> Sent: Tuesday, May 05, 2009 8:25 PM
> To: Bresticker, Shalom; Gordon Vreugdenhil
> Cc: sv-ec@server.eda.org
> Subject: RE: [sv-ec] Definition of access for class parameters.
> 
>  
> I uploaded the proposal to mantis # 2575.
> The proposal I submitted takes care of several mantis items. It was a
> decision we
> made to treat mantis items 2575, 2608 and 2598 together in 
> one proposal.
> 
> Francoise
>     '
> 
> -----Original Message-----
> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
> Sent: Tuesday, May 05, 2009 4:57 AM
> To: Francoise Martinolle; Gordon Vreugdenhil
> Cc: sv-ec@server.eda.org
> Subject: RE: [sv-ec] Definition of access for class parameters.
> 
> Where? I don't see it.
> It should be Mantis 2608.
> 
> Shalom 
> 
> > -----Original Message-----
> > From: Francoise Martinolle [mailto:fm@cadence.com]
> > Sent: Monday, May 04, 2009 9:23 PM
> > To: Bresticker, Shalom; Gordon Vreugdenhil
> > Cc: sv-ec@server.eda.org
> > Subject: RE: [sv-ec] Definition of access for class parameters.
> > 
> >  
> > New proposal considering your comments has been uploaded to Mantis.
> > 
> > Francoise
> >     '
> > -----Original Message-----
> > From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> > Sent: Sunday, May 03, 2009 12:28 AM
> > To: Francoise Martinolle; Gordon Vreugdenhil
> > Cc: sv-ec@server.eda.org
> > Subject: RE: [sv-ec] Definition of access for class parameters.
> > 
> > Hi,
> > 
> > This is the first time I have looked at this.
> > 
> > The term "parameter", unless specifically qualified as "value 
> > parameter"
> > or "type parameter", is a generic term including both. If the term 
> > "parameter" is intended to specify only value parameters, 
> it needs to 
> > say so explicitly. On the other hand, if both are meant, 
> there is no 
> > need to specify both.
> > 
> > Thus, for example, where 8.17 says, "Class parameters and 
> class local 
> > parameters are also public," this includes both value and type 
> > parameters.
> > 
> > Where 8.22 says, "A class parameter, type parameter or 
> local param is 
> > a public element of a class," the use of "type parameter" 
> is redundant
> 
> > because it is included in "class parameter".
> > 
> > The text should be consistent in order to avoid confusion.
> > 
> > The use of "local param" should be avoided. It should be 
> either "local
> 
> > parameter" or "localparam".
> > 
> > At the end of the proposal, on page 4, there is some extra text.
> > 
> > Thanks,
> > Shalom
> > 
> > > -----Original Message-----
> > > From: owner-sv-ec@server.eda.org
> > > [mailto:owner-sv-ec@server.eda.org] On Behalf Of Francoise
> > Martinolle
> > > Sent: Saturday, May 02, 2009 1:31 AM
> > > To: Gordon Vreugdenhil
> > > Cc: sv-ec@server.eda.org
> > > Subject: RE: [sv-ec] Definition of access for class parameters.
> > > 
> > >  
> > > Second version of the class parameter specification which 
> addresses 
> > > Gordon's comments.
> > > 
> > > -----Original Message-----
> > > From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> > > Sent: Friday, May 01, 2009 4:54 PM
> > > To: Francoise Martinolle
> > > Cc: sv-ec@eda.org
> > > Subject: Re: [sv-ec] Definition of access for class parameters.
> > > 
> > > Francoise, this looks pretty good to me.  Thanks for
> > working through
> > > the details there.
> > > 
> > > One detail lies in the grammar -- a constant_primary only 
> admits a 
> > > ps_parameter_identifier which does allow the syntactic form
> > name::name
> > 
> > > but where the LRM uses package_name to indicate intent for
> > the prefix.
> > > Ideally I think that should be fixed in the grammar.
> > > We might also consider explicitly stating that
> > class_type::parameter
> > > is a constant expression.  That likely isn't needed with
> > the grammar
> > > change, but it makes the asymmetry with the "this." and "super."
> > > more explicit and obviously intentional.
> > > 
> > > Gord.
> > > 
> > > Francoise Martinolle wrote:
> > > > Attached is a proposal for specifying access to class
> > > parameters, type
> > > 
> > > > parameters and local class parameters.
> > > >  
> > > > Mantis is not working so I have not uploaded the proposal.
> > > >  
> > > > Francoise
> > > >        '
> > > > 
> > > > --
> > > > This message has been scanned for viruses and dangerous 
> content by
> > > > *MailScanner* <http://www.mailscanner.info/>, and is
> > believed to be
> > > > clean.
> > > 
> > > --
> > > 
> --------------------------------------------------------------------
> > > Gordon Vreugdenhil                                503-685-0808
> > > Model Technology (Mentor Graphics)                
> gordonv@model.com
> > > 
> > > 
> > > --
> > > This message has been scanned for viruses and dangerous 
> content by 
> > > MailScanner, 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.
> > 
> > 
> ---------------------------------------------------------------------
> 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.
> 
> 
---------------------------------------------------------------------
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, and is
believed to be clean.
Received on Tue May 5 10:48:41 2009

This archive was generated by hypermail 2.1.8 : Tue May 05 2009 - 10:48:52 PDT