Skip to content

FEATURE IDEA: Operator overloading

Jump to bottom
Maaartinus edited this page Apr 16, 2018 · 3 revisions

IDEA

Lombok can try to scan for a + b where a and/or b is of type BigDecimal or BigInteger and the other is any of Number, any numeric primitive, or BigDecimal/BigInteger, and 'fix' it.

CONCERNS

  • Both @rspilker and @rzwitserloot think operator overloading is a feature that has been abundantly proven as causing far more harm than help. As a consequence, the feature will not be user-extensible, but on the plus side, that does mean we don't have to worry about hairy questions such as: What if the left-hand side has a defined overload, and the RHS also does.. which one wins?

  • Requires resolution, and would require lombok to scan just about everything; it'll slow down compilation quite a bit.

  • It's quite different from what lombok normally does: Lombok always triggers on some type in the lombok package (usually an annotation, but sometimes just a type, like lombok.val) – for this feature, lombok triggers anytime you attempt to add 2 BigInteger objects together, for example. This means the transformation would be entirely magical (no annotation to highlight that lombok is doing things to your code).

CURRENT STATUS: Don't hold your breath. @rspilker and @rzwitserloot have no intention on working on this. Please contact us BEFORE trying to work on a feature request, as we might deny it outright for being too convoluted. Some solutions to the above problems, particularly the 'it's so magical' part of it, would probably be needed for us to consider it as a PR.

AN IDEA: Require @lombok.Operators on the class (or maybe method) for switching the magic on. It speeds up the compilation as most classes probably use no BigDecimal/BigInteger, it gives at least some hint to the reader and it provides a link to the documentation. Forgetting the annotation is no real problem as the first syntax error gently reminds you.

Clone this wiki locally