- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Units of Measurement — Scala Macros to the rescue?
Hi everyone,
as some people know, I have been working on the Units of Measurement functionality of metascala, where a unit is represented by a numerical value for quantity and 7 generic types representing the SI units.
The last two major things missing in my book are implementations of toString, equals and probably hashCode. They are currently not really implementable, because they depend on the generic types which are not available at runtime.
Would macros enable me to implement these operations by looking at them at compile time? E.g. implementing equals by checking that the two compared instances have the same generic types with a macro and refusing to compile if they don't?
Thanks and bye,
Simon
as some people know, I have been working on the Units of Measurement functionality of metascala, where a unit is represented by a numerical value for quantity and 7 generic types representing the SI units.
The last two major things missing in my book are implementations of toString, equals and probably hashCode. They are currently not really implementable, because they depend on the generic types which are not available at runtime.
Would macros enable me to implement these operations by looking at them at compile time? E.g. implementing equals by checking that the two compared instances have the same generic types with a macro and refusing to compile if they don't?
Thanks and bye,
Simon
Re: Units of Measurement — Scala Macros to the rescue?
Hashcode has the same problem, it should also be based on the value and the unit, but only the value is available at runtime.
Re: Units of Measurement — Scala Macros to the rescue?
On Sat, Feb 4, 2012 at 09:16, Simon Ochsenreither
wrote:
> Sorry, I completely disagree. Imho it is dozen times worse to have two
> methods where of them is just not working, because it can only compare the
> value, but not the types. An alternative would be to implement equals by
> always throwing an exception. But then I would just prefer making a known
> wrong equals comparison a compile time error instead.
That's why libraries such as Scalaz have a different equality
comparison. If you do this, then you are basically breaking both your
equals methods and Scala's equals method, so that we end with NO
equals method. Except, of course, for Scala.
I'm all for fixing equality, but either it is done for everything, or
it is done for nothing. I can compromise on it remaining broken, but
not on having two different versions with the same name.