Would it make sense to add Level to the quantity package here? about unit-api HOT 11 CLOSED

A) Move Level to javax.measure.quantity here

from unit-api.

B) Move Level to si-quantity

from unit-api.

@unitsofmeasurement/experts, @unitsofmeasurement/contributors What is your preference? TIA, Werner

from unit-api.

Maybe if the current Level javadoc were updated with an example of how it relates to Bel (as an example), it would help to get a better idea? The weight I worry about is not the 320 bytes, but more about the conceptual weight of the API.

from unit-api.

I have no strong preference here. My gut-feeling also suggests maybe leave it to SI here as well.
P.s.: If you wish to improve JavaDoc, please do in the current place: https://github.com/unitsofmeasurement/uom-systems/blob/master/quantity/src/main/java/systems/uom/quantity/Level.java

from unit-api.

I voted on B now. Since the ISQ defines Level it is generally intended for use with ISO 80000, etc. but BEL or DECIBEL being permitted with the SI as well means, and the Wikipedia page states "The ISQ defines the quantities that are measured with the SI units", it should be in SI Units. I take @desruisseaux remarks as leaning more towards B as well? Would be nice to have at least a third @unitsofmeasurement/experts member confirm this if possible.

from unit-api.

I voted for option A because it seems like a conceptual thing part of the units domain, and not something connected to a system (SI or not). I can imagine that other systems may want to use the Level interface too. Imagine a weird system measuring lengths in a logarithmic way, shouldn't it use a Level interface from the unit API rather than borrowing a Level interface from the SI system?

On the other hand, I'm not sure I understand the Level interface entirely. Does e.g. the multiply method, inherited from the Quantity interface, make sense in it?

from unit-api.

Thanks for voting. There is a certain point because although the ISQ has ties to the SI system, pretty much all quantities mentioned there (derived ones are just a small subset) are in the quantity package here in the API module. Every quantity inherits the methods from Quantity, that includes Dimensionless, previously used for NEPER, BEL or DECIBEL in JScience. The second level of generic typing allows to define what each of these are, the UCUM system shows a couple of use cases already.

from unit-api.

@andi-huber What's your opinion on this? We have 2 thumbs and one statement somewhat leaning more towards the SI module. If we get one or two extra votes, I'd love to wrap it up and refactor the Level interface to the desired place.

from unit-api.

I think you all made good points here. I have no strong preference.

Maybe go with B) for now and leave option A) as a future possibility, in case it turns out that A) makes more sense!?

from unit-api.

Thanks, then based on my initial vote/thought, the concerns @desruisseaux raised here and your input we have a stronger point for B. And you're right, we could either with an MR or similar future version of the API still add it there. I'll close this issue and create an action item for si-units if it's not there already.

from unit-api.