Clarification on migration to value types and boxed vs unboxed representations

[Vitaly Davidovich]

The re-reading a value type into interface causing boxing is typically
solved (again, using .net as an example) by having constrained generic
methods that are constrained to receiving an interface type (or subtype),
I.e. using the "where" clause in c#.  In those cases, there's no boxing.
With specialization, I imagine that will work as well although need to see
if/how constraints will be surfaced.

Sent from my phone
On Jan 5, 2015 9:36 PM, "Richard Warburton" <richard.warburton at gmail.com>
wrote:

> Hi,
>
> Thanks for your reply John - that clarified a lot.
>
> > Its probably worth also noting at this point that about 18 months ago the
> > > LJC ran a hackday on the IBM Packed Objects proposal which has some
> > overlap
> > > with value types. One of the things that people found most confusing
> was
> > > that packed objects had a transparent way of returning what was called
> a
> > > "proxy object". So that's like a boxed version of the packed object. It
> > was
> > > not at all obvious when looking at the code that you wrote as to
> whether
> > > you were referring to the packed or the proxy object. I suppose part of
> > > that was not being able to easily refer to a spec - but part of it is
> > just
> > > the general opaqueness of implicit conversions in general.
> >
> > Key question:  How did users experience the difference between the packed
> > and the proxy version?
> >
> > In that design it might have been because of side effects viewed through
> a
> > surprising alias (since packed values are manipulated by-reference).
> Value
> > types as proposed do not have that set of surprises, because they are
> > immutable.
> >
>
> No - I think the confusion was that you couldn't look at the code and
> obviously see what was a reference and what was packed when thinking about
> the object graph. This applied to reading from values as much as writing to
> them. I appreciate that mutability adds its own set of confusions but IMHO
> this wasn't one of them.
>
> > Having a similar situation with value types would be a real shame. Would
> > it
> > > be possible to clarify when value types become converted to their boxed
> > > equivalents?
> >
> > If you cast a value to Object you get a box.  Just like casting an int to
> > an Object.  ("Codes like a class, works like an int.")  The syntax for
> > naming the box-type for a value V is TBD; there are not many use cases
> for
> > it.  (Bad bikeshed color of the moment:  V&Object.)
>
>
> That's re-assuring to know. I guess of more concern to me is that
> re-reading once I assign the value to an interface there will be boxing
> (right?), and this seems a lot trickier to spot than the explicit casting
> case. I'll try to keep an eye out for this situation.
>
> regards,
>
>   Richard Warburton
>
>   http://insightfullogic.com
>   @RichardWarburto <http://twitter.com/richardwarburto>
>