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

I don't really have a strong opinion on this one, but...

I'd rather have a much stronger reason to make something legal, than to
make it illegal. Once you make it legal, it's very difficult to remove
it later if we find problems with it. 

I am constantly amused by the creative uses of the language no one had
ever dreamed of doing when it was being written. Unfortunately, this
usually opens up the door for whole areas of underspecified behavior.

Dave


> -----Original Message-----
> From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
> Sent: Saturday, March 18, 2006 12:09 PM
> To: 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.
> 
> Dave,
> 
> What you propose is a sledgehammer approach to something that may or
may
> not be desirable. Why not let users decide?
> 
> I agree with Neil that allowing static variables to participate in
> streaming is in most cases a desirable feature. I believe the biggest
> concern is the global side effect of streaming a bit-stream onto a
class
> containing static variables (not the other way around), but I fail to
> see why that is any worse than an explicit assignment to the static
> variables. Shouldn't we assume that users know what they're doing?
> 
> Also, this is very different from disallowing access to local and
> protected member from outside. In that case, we are simply stating
that
> the existing access rules should be consistent for all operators,
thus,
> avoid giving special access permissions to the bit-stream operators.
> That operation is still perfectly valid when specified in a method of
> that class.
> 
> 	Arturo
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Rich, Dave
> Sent: Friday, March 17, 2006 4:49 PM
> To: 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'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
> >
---------------------------------------------------------------------
> >
>