search

unitsofmeasurement / indriya

JSR 385 - Reference Implementation
Other
119 stars 42 forks source link

Could NumberQuantity also be final? #318

Closed keilw closed 2 years ago

keilw commented 3 years ago

The other subclasses of AbstractQuantity TemporalQuantity and TimeUnitQuantity are final. Could we also make NumberQuantity final? It would blend in with the concept of Value-based Classes which essentially all Quantity implementations are.

keilw commented 3 years ago

@andi-huber What's your opinion on that? All other specialized Quantity subtypes like DecimalQuantity etc. are final, so is there a point e.g. extending it why we should leave NumberQuantity non-final, or can we also make it final?

andi-huber commented 3 years ago

Hi @keilw - I have no strong opinion on that. Technically no objections to making NumberQuantity final.

But I wonder, why not going the opposite direction and remove final from the other AbstractQuantity specializations. If consumers of the library potentially have any use-cases of sub-classing eg. NumberQuantity, then why not?

keilw commented 3 years ago

I believe most of them are package private for a good reason they are internal classes nobody should use. Interestingly BigDecimal or BigInteger are not final, but that might be for historic reasons. While I'm often sceptical of the "religious fervor" by folks like Stephen Colebourne that many of them (or the rest of the JDK team) are the first to breach, I see nothing wrong in adopting this "value-based" idea. Especially since Quantity instances much more than e.g. Optional (which is more a wrapper around values than value-based itself ;-) fall into that category. Plus I see future benefit in the whole "Valhalla" efforts wherever they ultimately lead us (hopefully not just something like the broken annotation JSRs like 305 or 308) and a future Java 16 variation of classes like NumberQuantity might be annotated according to https://openjdk.java.net/jeps/390, so I would say make it final.