5

According to the documentation on value classes, they may be allocated under a number of circumstances:

Allocation Summary

a value class is treated as another type.

a value class is assigned to an array.

doing runtime type tests, such as pattern matching.

Is there anyway to say,throw a compilation error if these circumstances occur?

Community
  • 1
  • 1
J Pullar
  • 1,915
  • 2
  • 18
  • 30
  • 2
    Can you elaborate more on *why* you want to do that? – Yuval Itzchakov May 13 '16 at 10:44
  • 2
    The whole motivation behind value classes is they disappear at run time. No memory allocation, but if I cant control that, the motivation goes away. (Im creating a type safe Json approach without having to actually wrap each value type in a Json type, say like argonaut does) – J Pullar May 13 '16 at 11:11
  • Why do you need compile time warnings then? You know precisely when you're making an allocation. – Yuval Itzchakov May 13 '16 at 11:35
  • Are you familiar with Value Classes? http://docs.scala-lang.org/overviews/core/value-classes.html The compiler does the allocation – J Pullar May 13 '16 at 11:47
  • The motivation for value objects isn't to completely eliminate object allocations, but to minimize them - just like the types `Int`, `Long`, and so on, are represented as primitives whenever possible, but get silently boxed/unboxed as necessary. Besides, if your goal is to optimize the performance/memory usage profile of your library, you will need to do some serious profiling to find the real bottlenecks anyway - so this sort of concern smells like premature optimization to me. – Cyäegha May 13 '16 at 11:59
  • Have you read the introduction to the SIP? It is exactly the motivation. – J Pullar May 13 '16 at 12:05
  • And then to obscure varification of motivation Im finding a bit odd – J Pullar May 13 '16 at 12:05
  • @JPullar Yes, I am well aware of what value classes are. Perhaps you didn't understand my question. If you know exactly when such a class causes an actual allocation of an object, you can avoid it without the help of the compiler by remembering when such an allocation occurs. – Yuval Itzchakov May 13 '16 at 12:47
  • @JPullar Or are you afriad of other developers making that "mistake"? – Yuval Itzchakov May 13 '16 at 12:48
  • Yes, bang on, definitely stopping other developers making that mistake. Despite the clear definition I also find Im getting allocations where I didn't expect them. It would be nice if the compiler could assist in ironing these out. – J Pullar May 13 '16 at 13:11
  • I guess, Im not always sure when I might be performing a runtime type test. – J Pullar May 13 '16 at 13:33

1 Answers1

1

There is nothing built-in (AFAIK).

You could write an SBT plugin which inspects the .class files after compile task finishes (using a library like BCEL, ASM, etc.) and fails if it finds any value class constructor calls.

Alternately, you should be able to do the same with a compiler plugin (unfortunately, documentation I was able to find is quite old) with a little more difficulty.

Alexey Romanov
  • 167,066
  • 35
  • 309
  • 487
  • It might be possible to check in the posterasure compiler stage the resulting state of the elimErasedValueType. Perhaps check for an annotation on the value class? – J Pullar May 14 '16 at 11:33
  • Actually, more likely earlier, in the TypeAdaptingTransformer, box method – J Pullar May 14 '16 at 11:41