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

I'm almost of the opinion that if the class contains static members, we
should make a bitstream of that class illegal, just like we have just
proposed for local and protected members. I think local and protected
members are used much more pervasively than static members. So that
limits bitstream casting of classes to only the simplest forms. That
should motivate people to use user defined pack and unpack methods
instead.

Dave


> -----Original Message-----
> From: Neil Korpusik [mailto:Neil.Korpusik@Sun.COM]
> Sent: Friday, March 17, 2006 2:11 PM
> To: Vreugdenhil, Gordon
> Cc: Rich, Dave; Arturo Salz; 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 don't view this as a problem.
> 
> > Should casting back into a particular object effect class-wide
> > static properties?
> 
> Yes, it should.
> 
> One must be very careful when choosing to use static properties. You
have
> pointed out one case which needs to be considered. Yes, you end up
> changing
> the statics for all instances when restoring the state of an instance
of
> that class. That is how statics work.
> 
> 
> 
> Gordon Vreugdenhil wrote On 03/17/06 14:01,:
> > A static property is definitely non-constant but it is really
> > associated with the type, not the object.
> >
> > If, as stated in 22.3, the intent is:
> >
> >     [Variable b can be used] to hold the bit pattern of a variable
of
> [type
> >     MyType] without loss of information.
> >
> > then we have a fundamental problem since if:
> >     a) you don't include the statics then you don't have all the
> >        information
> >     b) you include the statics but then you can't "recover" the
> >        state without impacting the state of every other object of
> >        the type.
> >
> > Should casting back into a particular object effect class-wide
> > static properties?  That seems to be problematic.
> >
> > Since the user can always write their own, I think that the
> > statics should be excluded by default so that reading back
> > into an object won't, by default, impact class static properties.
> >
> > Gord
> >
> >
> >
> > Neil Korpusik wrote:
> >
> >
> >>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
> ---------------------------------------------------------------------
>