About signature for toUnit() function

[IndrajeetPatil]

Is it just me or the signature for toUnit() function

toUnit(quantityOrDimension, values, targetUnit, molWeight, sourceUnit, molWeightUnit)

should instead be?

toUnit(quantityOrDimension, values, targetUnit, sourceUnit, molWeight, molWeightUnit)

As a new user, I was constantly befuddled by the fact that the target and source unit parameters were not in succession.

[PavelBal]

Yeah we did not have the argument sourceUnit in the first implementation (it was always assumed to be in base unit. To not to break existing code, we decided not to change the order of the arguments.

[msevestre]

yep that

[IndrajeetPatil]

Hmm, so we need to live with this order for the rest of the eternity? Pity.

[msevestre]

no I don't think so.
I think most people use named argument anyways
And if not, this will crash as the argument have different types
I am ok to change this

[msevestre]

specifrically because we are introducing some braking changes

[PavelBal]

@IndrajeetPatil Please also open an issue in esqlabs-r to check the code using toUnit.

[IndrajeetPatil]

I checked all instances of usage, and nowhere does esqlabsR uses positional argument matching.

So this change doesn't break anything in esqlabsR! 🙌

[IndrajeetPatil]

I also went through usage instances in the OSP organization, and none of them will break either!