Re: Request for API change (hopefully minor)

[Werner Keil]

Thanks, but given the ICU and Unicode Consortium is a group similar to JCP with companies even including Apple or Microsoft(!) involved (though they don't seem to care about Java unlike IBM, Google, Oracle and others) it is unlikely ICU4J would adopt Unit-API until e.g. parts inspired by it became a JSR ;-/

What I meant is a combination of ICU4J Measure to use its foundations especially for Unicode and the Unit/Measure base types, but implementing Quantity and related Unit-API interfaces for typesafe unit support.

http://git.eclipse.org/c/uomo/org.eclipse.uomo.git/tree/bundles/org.eclipse.uomo.units/src/main/java/org/eclipse/uomo/units/QuantityAmount.java

Its method
@SuppressWarnings("unchecked")
public Unit<Q> getQuantityUnit() {
return (Unit<Q>) getUnit();
}

implements what IMeasure currently calls getQuantityUnit().

Java has no method overloading to change the return value of a subclass, so if IMeasure or its supertype Quantity contained a method getUnit() it would break the code.

In an ideal world ICU4J would apply Unit-API and other efforts for type-safety like JSR-308 as soon as possible, but with companies like IBM involved where the project lead already told me earlier, he wasn't even allowed to look at JSR-275 code without written approval by his boss which the mail system (Notes;-) was said to have swallowed, you understand, it is unlikely to happen before the end of the decade in reality, probably never.
Same for applying JSR-310, while in some cases, ICU4J will remain superior to what Stephen envisions for 310 or what JodaTime provides so far, and those two also are unlikely to be "married" in the near future, despite IBM's effort for OpenJDK...

I hope, you understand that, also by being involved in other standard groups and Open Source communities, and might find some other method names a working and acceptable solution?

It was not me who changed some of these in the first place, it has spread across Java ever since version 5 driven by people like Josh Bloch, Doug Lea (though he mostly focused on concurrency AFAIK) or Mark Reinhold and some of those no longer at Oracle...

Regards,
Werner
-------- Original-Nachricht --------
> Datum: Thu, 27 Oct 2011 15:40:14 +0200
> Von: Martin Desruisseaux <martin.de...@geomatys.fr>
> An: Werner Keil <werne...@gmx.net>
> CC: unit...@googlegroups.com, daut...@gmail.com, units...@googlegroups.com, unitsof...@jscience.dev.java.net
> Betreff: Re: Request for API change (hopefully minor)

> Le 27/10/11 13:47, Werner Keil a écrit :
> > A getUnit() method with a signature like Unit<Q> is unfortunately an
> absolut no-go, as it'll completely break the ability to use ICU4J which
> already has this method (in a less typesafe way) returning a MeasureUnit:
> > http://icu-project.org/apiref/icu4j/com/ibm/icu/util/Measure.html
>
> You mean assuming that com.ibm.icu.util.Measure wants to implement
> org.unitsofmeasurement.quantity.Quantity?
>
> If com.ibm.icu.util.MeasureUnit implements
> org.unitsofmeasurement.unit.Unit,
> then there is no problem at all... I attached to this email a patch to
> ICU4J
> 4.8.1.1 showing that it works (I did not bother to implement the Unit
> methods
> however - just throwing UnsupportedOperationException for now).
>
>
> > Thus, although Unit-API so far doesn't define annotations, would you be
> happy if we took this pattern for:
> >
> > public interface Quantity<Q extends Quantity<Q>> {
> > public Unit<Q> unit();
> > public Number value();
> > }
>
> I'm totally fine with that.
>
> Martin
>

--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone

[Werner Keil]

That would be AbstractUnit:
http://git.eclipse.org/c/uomo/org.eclipse.uomo.git/tree/bundles/org.eclipse.uomo.units/src/main/java/org/eclipse/uomo/units/AbstractUnit.java
but it didn't seem to compile once Quantity or its sub-interface IMeasure got a method with identical name as in ICU Measure.

I know patches for UOMo based on Git may be a little complicated, I wouldn't ask to do a private fork just for that, but if you come across a very simple test case that compiles, I'd appreciate.

I saw articles like this:
http://www.java-tips.org/java-se-tips/java.lang/covariant-return-types.html

And wouldn't outrule, Maven or Eclipse for a certain UOMo release may have compiled in a backward-compatible mode. Will try to verify.
ICU4J for sure was compiled without special Java 5 options, at least until recently, to make it backward-compatible with older systems.

Thus, if it only works for all JARs and their content being entirely Java 5 and beyond, there is a level of uncertainty, also on other platforms like Android.

I'm happy to check, but if you are open to a simplified method naming, regardless we might consider using those method names.

@Jean-Marie, please confirm for JScience, both the new method names for Quantity and Exception.

Thanks and Regards,
Werner

-------- Original-Nachricht --------
> Datum: Thu, 27 Oct 2011 16:30:07 +0200

> Von: Martin Desruisseaux <martin.de...@geomatys.fr>
> An: Werner Keil <werne...@gmx.net>

> CC: unitsof...@jscience.dev.java.net, units...@googlegroups.com, daut...@gmail.com, unit...@googlegroups.com

> Betreff: Re: Request for API change (hopefully minor)

> Le 27/10/11 16:09, Werner Keil a écrit :

> > Java has no method overloading to change the return value of a subclass,
> so if IMeasure or its supertype Quantity contained a method getUnit() it
> would break the code.

> Well, you can change the return value to any sub-type of Unit - this is
> called
> return type covariance. So you could:
>
> * Define a com.ibm.icu.util.MeasureUnit subclass which implement Unit<Q>
> * In org.eclipse.uomo.units.QuantityAmount, override the getUnit()
> method in
> order to return the class defined above.
>
>
> That should work.

>
> > I hope, you understand that, also by being involved in other standard
> groups and Open Source communities, and might find some other method names a
> working and acceptable solution?

> No problem, actually I really like the value() / unit() names that you
> suggested, so the proposal you made in the previous email would be perfect
> for
> me :-). My patch in the previous email and the above proposal is just in
> case
> you want to retrofit the Unit-API nicely in ICU4J. This is technically
> possible,
> but is not goal for me so the choice is really you :-) (or other UOMo
> developers).

[Werner Keil]

We could try, I'm curious, at least with the most recent ICU4J versions it should work.

Unless Jean-Marie/JScience strongly objects, I'd be happy with the getter-less method names.

Thanks,
Werner

-------- Original-Nachricht --------
> Datum: Thu, 27 Oct 2011 17:03:25 +0200

> Von: Martin Desruisseaux <martin.de...@geomatys.fr>
> An: Werner Keil <werne...@gmx.net>

> CC: unit...@googlegroups.com, daut...@gmail.com, units...@googlegroups.com, unitsof...@jscience.dev.java.net

> Betreff: [unitsofmeasurement] Re: Request for API change (hopefully minor)

> Le 27/10/11 16:48, Werner Keil a écrit :

> > Thus, if it only works for all JARs and their content being entirely
> Java 5 and beyond, there is a level of uncertainty, also on other platforms
> like Android.
>

> Yes, I'm perfectly happy with unit() / value() method names. Do we want to
> go
> that way?
>
> Do you still want me to look for a UOMo patch using getValue() / getUnit()
> method names? I'm 99% sure that I can do this patch, but this is really up
> to you.
>
> Martin
>

--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

[Martin Desruisseaux]

[Martin Desruisseaux]

Le 27/10/11 16:48, Werner Keil a écrit :

> Thus, if it only works for all JARs and their content being entirely Java 5 and beyond, there is a level of uncertainty, also on other platforms like Android.

Yes, I'm perfectly happy with unit() / value() method names. Do we want to go

[Martin Desruisseaux]

Le 27/10/11 16:09, Werner Keil a écrit :

Java has no method overloading to change the return value of a subclass, so if IMeasure or its supertype Quantity contained a method getUnit() it would break the code.

Well, you can change the return value to any sub-type of Unit - this is called return type covariance. So you could:

• Define a com.ibm.icu.util.MeasureUnit subclass which implement Unit<Q>

• In org.eclipse.uomo.units.QuantityAmount, override the getUnit() method in order to return the class defined above.
  

That should work.

I hope, you understand that, also by being involved in other standard groups and Open Source communities, and might find some other method names a working and acceptable solution?

No problem, actually I really like the value() / unit() names that you suggested, so the proposal you made in the previous email would be perfect for me :-). My patch in the previous email and the above proposal is just in case you want to retrofit the Unit-API nicely in ICU4J. This is technically possible, but is not goal for me so the choice is really you :-) (or other UOMo developers).

    Martin

[Jean-Marie Dautelle]

Hi Guys,

Sorry I read the conversation late. Today I worked on dimensional anlysis for JScience (ref. JScience SVN package org.jscience.physics.dimension). After reading on the subject (http://en.wikipedia.org/wiki/Dimensional_analysis). I came to the conclusion that Quantity is a fundamental concept to which dimensions can be mapped. But quantities do not have intrinsic units associated with (unlike measurement). Furthermore some discussions of dimensional analysis implicitly describe all quantities as mathematical vectors, ref. position vs displacement chapter.

Therefore, the correct definition for a Quantity would be:

interface Quantity<T, Q extends Quantity<T, Q>> {

    T getValue(Unit<Q> unit);

}

For subclasses:

interface Force<T> extends Quantity<T, Force>> {}

And finally you could have: Force<Number> affine quantity which can be used in GeoAPI (equivalent to what you were looking for)

and Force<Vector> vector quantity (e.g. Torque).  Let me know what you think.

 

Best regards,

Jean-Marie.

--
As a well spent day brings happy sleep, so life well used brings happy death - ‹(•¿•)› Leonardo da Vinci