Re: [sv-ec] Q: Should local or protected members of a class be excluded from a bit stream cast.

From: Neil Korpusik <Neil.Korpusik_at_.....>
Date: Fri Mar 17 2006 - 13:40:20 PST
The stream should always contain all of the properties.

It is true that all instances of the class share static properties, but I don't
see that as being a good reason to exclude those properties from the stream.
I believe that it was always our intent to include all of the properties
in the stream.

Users of classes don't think of a static property as being part of the type.
The values of static properties can vary. They aren't constants. Anything
that is part of a type has a constantness to it.

Perhaps subclause 7.8 is not as clear as it should be. I could see how one
might come away with the impression that a static property is fixed to a
particular value. The intent is for a static property to be a shared property,
not a constant valued property.


Neil



Rich, Dave wrote On 03/17/06 09:21,:
> And here's a related issue that I will tack onto a proposal for mantis
> 1384.
> 
> Should static members of class be part of the stream? The internal
> discussion here was that they should not. A static member is part of the
> type, not the instance.
> 
> Dave
> 
> 
> 
>>-----Original Message-----
>>From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
>>Sent: Tuesday, March 14, 2006 11:34 PM
>>To: Neil.Korpusik@Sun.com; Rich, Dave
>>Cc: sv-ec@eda.org
>>Subject: RE: [sv-ec] Q: Should local or protected members of a class
> 
> be
> 
>>excluded from a bit stream cast.
>>
>>I tend to agree. I see no reason why the access granted to the
> 
> streaming
> 
>>operators should be any differently than for any other operator.
>>
>>	Arturo
>>
>>-----Original Message-----
>>From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> 
> Neil
> 
>>Korpusik
>>Sent: Tuesday, March 14, 2006 4:29 PM
>>To: Rich, Dave
>>Cc: sv-ec@eda.org
>>Subject: Re: [sv-ec] Q: Should local or protected members of a class
> 
> be
> 
>>excluded from a bit stream cast.
>>
>>I agree with your position on this.
>>
>>Trying to access a protected or local property from outside the class
>>should be illegal. Accessing a subset of the properties when using
>><<, >> or a bitstream cast on a class handle is not appropriate.
>>Instead, it should be considered an illegal attempt to access the
>>local or protected properties.
>>
>>
>>Neil
>>
>>
>>
>>Rich, Dave wrote On 03/14/06 16:14,:
>>
>>>I was hoping to gather some opinions on this. Without any other
>>
>>comment,
>>
>>>I will propose to make it illegal.
>>>
>>>Dave
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Neil Korpusik [mailto:Neil.Korpusik@Sun.COM]
>>>>Sent: Tuesday, March 14, 2006 1:44 PM
>>>>To: Neil.Korpusik@Sun.COM
>>>>Cc: Rich, Dave; sv-ec@eda.org
>>>>Subject: Re: [sv-ec] Q: Should local or protected members of a class
>>>
>>>be
>>>
>>>
>>>>excluded from a bit stream cast.
>>>>
>>>>Mantis 1384 has been opened for this issue.
>>>>
>>>>Neil
>>>>
>>>>
>>>>
>>>>Neil Korpusik wrote On 03/14/06 11:04,:
>>>>
>>>>
>>>>>8.17 Sreaming operators (pack/unpack)
>>>>>
>>>>>This sub-clause discusses the use of << and >> on class handles.
>>>
>>>There
>>>
>>>
>>>>>doesn't appear to be any mention of local or protected properties.
>>>
>>>The
>>>
>>>
>>>>>same issue you are raising for a bit-stream cast seems to also be
>>>>
>>>>relevant
>>>>
>>>>
>>>>>to the streaming operators.
>>>>>
>>>>>Neil
>>>>>
>>>>>
>>>>>Rich, Dave wrote On 03/14/06 07:15,:
>>>>>
>>>>>
>>>>>
>>>>>>This raises a deeper issue. I thought the intent of
> 
> local/protected
> 
>>>was
>>>
>>>
>>>>>>just linting. You should be able to remove the 'local' and
>>>
>>>'protected'
>>>
>>>
>>>>>>keywords from code that previously compiled with no change in
>>>>>>functionality. Therefore, bit-stream casts with local members
> 
> should
> 
>>>be
>>>
>>>
>>>>>>illegal (unless you are bit streaming 'this').
>>>>>>
>>>>>>
>>>>>>
>>>>>>The latter seems a bit harsh, but are there other places
>>>
>>>local/protected
>>>
>>>
>>>>>>changes the semantics of an operator?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>Dave
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>---------------------------------------------------------------------
>>
>>-
>>
>>>--
>>>
>>>
>>>>>>*From:* owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On
> 
> Behalf
> 
>>>Of
>>>
>>>
>>>>>>*Rich, Dave
>>>>>>*Sent:* Monday, March 13, 2006 11:13 AM
>>>>>>*To:* sv-ec@eda.org
>>>>>>*Subject:* [sv-ec] Q: Should local or protected members of a class
>>>
>>>be
>>>
>>>
>>>>>>excluded from a bit stream cast.
>>>>>>
>>>>>>
>>>>>>
>>>>>>I think the answer should be yes, and this should be an erratum in
>>>
>>>the
>>>
>>>
>>>>LRM.
>>>>
>>>>
>>>>>>
>>>>>>David Rich
>>>>>>Verification Technologist
>>>>>>Design Verification & Test Division
>>>>>>Mentor Graphics Corporation
>>>>>>dave_rich@mentor.com
>>>>>>Office:   408 487-7206
>>>>>>Cell:     510 589-2625
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>--
>>
>>>---------------------------------------------------------------------
>>>
>>>>Neil Korpusik                                     Tel: 408-720-4852
>>>>Senior Staff Engineer                             Fax: 408-720-4850
>>>>Frontend Technologies - ASICs & Processors (FTAP)
>>>>Sun Microsystems
>>>>email: neil.korpusik@sun.com
>>
>>>---------------------------------------------------------------------
>>>
>>>
>>>
>>--
>>---------------------------------------------------------------------
>>Neil Korpusik                                     Tel: 408-720-4852
>>Senior Staff Engineer                             Fax: 408-720-4850
>>Frontend Technologies - ASICs & Processors (FTAP)
>>Sun Microsystems
>>email: neil.korpusik@sun.com
>>---------------------------------------------------------------------
>>
> 
> 
> 

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-720-4852
Senior Staff Engineer                             Fax: 408-720-4850
Frontend Technologies - ASICs & Processors (FTAP)
Sun Microsystems
email: neil.korpusik@sun.com
---------------------------------------------------------------------
Received on Fri Mar 17 13:40:24 2006

This archive was generated by hypermail 2.1.8 : Fri Mar 17 2006 - 13:40:35 PST