Value classes for primitive single-element message?

[seacourtaw]

Would it be possible for messages with one required field of value type to extend AnyVal? I am presuming not, but it's not completely clear from a cursory scan of the code.

[nadavsr]

Currently this is not the case. I believe we can do that and it would be relatively easy to add. Any reason this shouldn't be applied to non-primitive single-element messages?

[seacourtaw]

Hmm. Good question. In the particular use case I envision, I have a set of
classes representing physical units. At the moment they are value classes
(not from protos) and I have a set of methods that allow them to be
combined appropriately (e.g Speed * Time = Distance). I would like to be
able to serialise them (and the class hieararchy they live in) to proto.
ScalaPB looks great - but in the current formulation if I define a set of
single-element messages (and use typeclasses to extend with methods) I lose
the value class optimisation.

It could also be useful for non-primitive single-element messages. Either
way it'd be great to have.

On Fri Dec 19 2014 at 6:41:21 PM Nadav S. Samet notifications@github.com
wrote:

Currently this is not the case. I believe we can do that and it would be
relatively easy to add. Any reason this shouldn't be applied to
non-primitive single-element messages?

—
Reply to this email directly or view it on GitHub
#4 (comment).

[nadavsr]

I looked into this and the change isn't as straightforward as I hoped. Given that required fields are going to be dropped in the upcoming proto3 syntax, there is a little value in implementing this. I'm interested to know if the AnyVal optimisation makes a measurable performance difference in your use case and then we can figure out if it's worth the investment.

In the mean time, I suggest that you use your own case classes that extend AnyVal during the life of your program, and map them to/from protobufs when you need to serialize/deserialize.