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

Francoise,

I added the following note to Mantis 2575:

I don't think we should allow access to parameters via dotted expressions - handle.parameter or super.parameter. Parameters should
be accessible only via the class resolution operator. This is simple and straightforward rule, otherwise we have to make distinctions
between value parameters and type parameters and that is only bound to cause confusion.

Parameters are not class members in the sense that they don't represent proper L-values. They exist only in the compiler and they
may not be written.

That was my intent on mantis 2598 - where I would expect to add the note that parameters are accessible only via the :: operator.

        Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Francoise Martinolle
Sent: Tuesday, May 05, 2009 10:25 AM
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.


--
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.