Use Advanced Search to search the entire archive.
Re: Email proposal to the core-libs-dev@openjdk.java.net
- From: Werner Keil <
>
- To:
- Subject: Re: Email proposal to the
- Date: Mon, 20 Oct 2014 03:04:03 +0200
It would fracture the API and go against e.g. 354 design.
There is no logical reason for keeping
add(Unit)
or
multiply(Number)
In the API and throw others like
multiply(Unit) into impl, that would confuse users.
IMHO only cropping ALL operations if we really wanted to push them to impl
would work but be quite restrictive.
You know what happens if you put 1/2 into impl and leave other half in API.
We encourage people to use Quantity, not say DecimalQuantity or
AbstractQuantity (the factory returns it so most people don't even care
which one they got) so you'll have a method only on DecimalQuantity, then
you must do:
if (q instanceof DecimalQuantity) {
DecimalQuantity dq = (DecimalQuantity) q;
...
Cast pretty much inevitable, is that what you'd want?
While the existing ones work without that in most cases, you may use
asType() or not cast and use a generic value if you don't insist on the
type.
Werner
Am 20.10.2014 02:29 schrieb "Otávio Gonçalves de Santana" <
>:
>
Werner we could remove from the apiece and keep in the implementation.
>
On Oct 19, 2014 10:10 PM, "Werner Keil"
>
<
>
>
wrote:
>
>
> And just regarding the IoT guys at Eclipse, one asked about type-safety
>
> of these operations, but a choice of
>
> a) Cast
>
> b) asType()
>
> c) simply treat as <?> where no type needs to be defined
>
> seems fine, not just to me.
>
>
>
> I asked them, if they accepted or preferred those methods removed, but
>
> they have not answered it yet.
>
>
>
> Last time they did, they said they would like no combined multiply() and
>
> asType() in one method, it did not sound, like they wanted them both
>
> removed;-)
>
>
>
> HTH,
>
> Werner
>
> Am 20.10.2014 02:04 schrieb "Werner Keil"
>
> <
>:
>
>
>
>> I asked them, and they should come back during office hours, maybe got
>
>> the question Thu or Fri.
>
>>
>
>> Please especially Martin/Jean-Marie, would you be happy to "split" the
>
>> API?
>
>> Both on Quantity AND Unit of course, because the "crux" meaning all <?>
>
>> methods, Otavio feels are inappropriate result from Unit;-)
>
>>
>
>> Ideally a simple Yes/No, similar to what I asked the IoT guys.
>
>> The question, if you prefer cast and where applicable asType() was
>
>> answered, and except a minor issue with SE8 and asType() I am happy with
>
>> that, too.
>
>>
>
>> Now what about removing every <?> method:
>
>> divide() and multiply(<?>) invert() and potentially pow() from both
>
>> Quantity and Unit?
>
>> Again, doing it just on Quantity won't solve the problem, the Unit ones
>
>> operate like that and those change the type.
>
>>
>
>> WDYT?
>
>> Am 20.10.2014 01:12 schrieb "Leonardo Lima"
>
>> <
>:
>
>>
>
>>> Werner,
>
>>>
>
>>> What Otávio meant was an issue to discuss how to deal with it, because
>
>>> he (still) thinks <?> is not ok.
>
>>>
>
>>> You keep saying that "most IoT projects at Eclipse would want them
>
>>> removed either", name one, two, three persons in these projects, let them
>
>>> join our group (if not as experts, at least in the other mailing lists)
>
>>> and
>
>>> let them discuss with us, if /how should we deal with it so we all (EG
>
>>> and
>
>>> users) can play along...
>
>>>
>
>>> Regards,
>
>>> Leonardo.
>
>>>
>
>>> On Sun, Oct 19, 2014 at 9:02 PM, Werner Keil
>
>>> <
>
>
>>> wrote:
>
>>>
>
>>>> Nobody wants to remove them;-O
>
>>>> Neither Martin nor Jean-Marie, they want them to stay with <?>
>
>>>> wildcard.
>
>>>> I doubt, most IoT projects at Eclipse would want them removed either.
>
>>>>
>
>>>> If something like asType() can be found for Quantity, that would be a
>
>>>> good thing to add;-) It works for Unit and in most cases it should also
>
>>>> work for Quantity. A pure Dimension check as currently done with Unit
>
>>>> may
>
>>>> be a bit tricky here. Many custom types like BMI can be seen as
>
>>>> Dimensionless, but then if you declared such new quantities, will
>
>>>> telling
>
>>>> BMI.class from CO2Footprint.class or HeartBeat.class all work?
>
>>>> Expressing them purely via Quantity<?> seems fine, taking care of
>
>>>> proper formatting is far trickier. I told you we must focus on that, at
>
>>>> least for SI types, so e.g. ThePerfectStorm dealing just with standard
>
>>>> quantities produces adequate results.
>
>>>>
>
>>>> Regards,
>
>>>> Werner
>
>>>> Am 20.10.2014 00:43 schrieb "Otávio Gonçalves de Santana" <
>
>>>>
>:
>
>>>>
>
>>>> Ok Leonardo, waiting the issue to talk about remove these methods.
>
>>>>> On Oct 19, 2014 7:34 PM, "Leonardo Lima"
>
>>>>> <
>
>
>>>>> wrote:
>
>>>>>
>
>>>>>> I think that a nice round up is needed again :)
>
>>>>>>
>
>>>>>> We all but Werner would NOT like the "new signature", we (Leo,
>
>>>>>> Otávio, Martin and Jean-Marie) understood it breaks some rules and
>
>>>>>> logic.
>
>>>>>> Still, that doesn't solve some other problems and raises other
>
>>>>>> questions
>
>>>>>> like "should we remove the operation or not", but *that's for
>
>>>>>> another mail thread and JIRA issue*. JIRA #62 (and that mail
>
>>>>>> thread) is about changing the signature method.
>
>>>>>>
>
>>>>>> I really don't know if Werner is pushing for or against the new
>
>>>>>> signature (the new signature is the one proposed by Otávio).
>
>>>>>>
>
>>>>>> Werner, a simple yes and no question: do you want the new signature?
>
>>>>>>
>
>>>>>>
>
>>>>>> On Sun, Oct 19, 2014 at 6:51 PM, Werner Keil
>
>>>>>> <
>
>
>>>>>> wrote:
>
>>>>>>
>
>>>>>>>
>
>>>>>>> Am 19.10.2014 22:22 schrieb "Martin Desruisseaux" <
>
>>>>>>>
>:
>
>>>>>>> >
>
>>>>>>> > Bellow is my email proposal for the
>
>>>>>>>
>
>>>>>>> list (I may edit again tomorrow).
>
>>>>>>> Is there any objection or change proposal?
>
>>>>>>> >
>
>>>>>>> > Note the following risk: if we get an answer, I'm 100% sure that
>
>>>>>>> the answer will be that such break of parameterized type safety in
>
>>>>>>> the core
>
>>>>>>> JDK is a big no-no, with no excuse tolerated. Some peoples may be
>
>>>>>>> surprised
>
>>>>>>> that a JSR group considered such idea seriously enough for a debate,
>
>>>>>>> to the
>
>>>>>>> point of becoming reluctant to include anything coming from such
>
>>>>>>> group in
>
>>>>>>> the JDK.
>
>>>>>>> >
>
>>>>>>>
>
>>>>>>> That is out of discussion, since we propose a standalone JSR.
>
>>>>>>> If we succeed going 1.0 maybe some day a platform part could find
>
>>>>>>> it interesting, but I see that more likely on ME, than SE.
>
>>>>>>>
>
>>>>>>> > ________________________________
>
>>>>>>> >
>
>>>>>>> > Subject: Interpretation of parameterized type usage in a JSR
>
>>>>>>> >
>
>>>>>>> > Hello all
>
>>>>>>> >
>
>>>>>>> > My apologize for resorting to this mailing list for a question
>
>>>>>>> about an external API. I'm doing that, with agreement from other
>
>>>>>>> members of
>
>>>>>>> the JSR group, for a JSR which could possibly be proposed for
>
>>>>>>> inclusion in
>
>>>>>>> the JDK in some future version. I'm seeking confirmation about
>
>>>>>>> whether the
>
>>>>>>> following rule shall suffers no exception. In a nutshell (more
>
>>>>>>> detailed
>
>>>>>>> explanation below), given the following method signature where X, Y
>
>>>>>>> and Z
>
>>>>>>> are interfaces:
>
>>>>>>> >>
>
>>>>>>> >> X<Y> foo();
>
>>>>>>> >
>
>>>>>>> > I claim that it would be unacceptable to have the foo() method
>
>>>>>>> implementation actually returning instances of X<Z> through
>
>>>>>>> parameterized
>
>>>>>>> type erasure (ignoring cases like Collections.emptyFoo() where object
>
>>>>>>> properties do not depend on the parameter type). I claim that no
>
>>>>>>> "developer
>
>>>>>>> convenience" consideration can justify such breaking of Java
>
>>>>>>> parameter type
>
>>>>>>> safety. Some other peoples have the point of view that the developer
>
>>>>>>> should
>
>>>>>>> know what he is doing.
>
>>>>>>> >
>
>>>>>>> > Details
>
>>>>>>> >
>
>>>>>>> > In this discussion I use the standard Comparable<?> interface and
>
>>>>>>> its Short and Integer implementations for familiarity, but the
>
>>>>>>> actual JSR
>
>>>>>>> objects are different. Consider the following method:
>
>>>>>>> >>
>
>>>>>>> >> <X,Y> Comparable<?> multiply(Comparable<X> x, Comparable<Y> y);
>
>>>>>>> >
>
>>>>>>> > Let assume that the type of the return value is not necessarily
>
>>>>>>> the type, or a subtype, or a super-type of any of the arguments. It
>
>>>>>>> may be
>
>>>>>>> for example because the multiply method applies the Java rules of
>
>>>>>>> Binary
>
>>>>>>> Numeric Promotion (JLS §5.6.2). Consequently, the return type use
>
>>>>>>> the <?>
>
>>>>>>> wildcard since we can not express the actual return type as a
>
>>>>>>> function of X
>
>>>>>>> and Y with the parameterized type syntax. This force the users to
>
>>>>>>> cast as
>
>>>>>>> in the following example:
>
>>>>>>> >>
>
>>>>>>> >> Short x = 3;
>
>>>>>>> >> Short y = 4;
>
>>>>>>> >> Integer r = (Integer) multiply(x, y);
>
>>>>>>> >
>
>>>>>>> > For reasons out of scope of this email, some peoples want to use
>
>>>>>>> only the base interface:
>
>>>>>>> >>
>
>>>>>>> >> Comparable<Short> x = (short) 3;
>
>>>>>>> >> Comparable<Short> y = (short) 4;
>
>>>>>>> >> Comparable<Integer> r = (Comparable<Integer>) multiply(x, y);
>
>>>>>>> // Unsafe cast
>
>>>>>>> >
>
>>>>>>> > Some peoples in our JSR group feel very strongly against the <?>
>
>>>>>>> wildcard in return value. They consider it as a sign of bad design
>
>>>>>>> (note
>
>>>>>>> that I disagree - for me in this particular situation, it means "can
>
>>>>>>> not be
>
>>>>>>> expressed by the current Java parameterized type syntax". A JDK
>
>>>>>>> example of
>
>>>>>>> such case is Class.getEnclosingClass()). Some peoples are pushing
>
>>>>>>> for the
>
>>>>>>> following method declaration:
>
>>>>>>> >>
>
>>>>>>> >> <X,Y,R> Comparable<R> multiply(Comparable<X> x, Comparable<Y> y);
>
>>>>>>> >
>
>>>>>>> > In the above method signature X, Y and R appear independents -
>
>>>>>>> our relationship between (X,Y) and R is not expressed. Of course this
>
>>>>>>> method is impossible to implement without "unsafe cast" warnings,
>
>>>>>>> and those
>
>>>>>>> casts can not be proved to be safe. But that method signature allows
>
>>>>>>> users
>
>>>>>>> to write:
>
>>>>>>> >>
>
>>>>>>> >> Comparable<Short> x = (short) 3;
>
>>>>>>> >> Comparable<Short> y = (short) 4;
>
>>>>>>> >> Comparable<Integer> r = multiply(x, y);
>
>>>>>>> >
>
>>>>>>>
>
>>>>>>> What are you trying to explain here, the <?> version, or the
>
>>>>>>> proposed alternative?
>
>>>>>>> There's no need to cast required, so except the multiply() line
>
>>>>>>> the others seem unrelated and make no real sense.
>
>>>>>>>
>
>>>>>>> > The cast and the warning disappeared, which was the effect
>
>>>>>>> desired by the promoters. But that method signature also let users
>
>>>>>>> write:
>
>>>>>>> >>
>
>>>>>>> >> Comparable<Byte> r1 = multiply(x, y); // Wrong!
>
>>>>>>> >> Comparable<Float> r2 = multiply(x, y); // Wrong!
>
>>>>>>> >> Comparable<String> r3 = multiply(x, y); // Wrong!
>
>>>>>>> >> etc...
>
>>>>>>> >
>
>>>>>>> > Above code compile without warnings and can run, but will fail
>
>>>>>>> randomly at some later point when the assigned variables will be
>
>>>>>>> used. This
>
>>>>>>> is understood, but partisans of the later method signature said that
>
>>>>>>> developers should know what they are doing. My point of view is that
>
>>>>>>> no
>
>>>>>>> argument can justify to break the Java parameterized type safety
>
>>>>>>> that way.
>
>>>>>>> >
>
>>>>>>> > Alternative exists (e.g. not using parameterized types at all, do
>
>>>>>>> something similar to Class.cast(Object), etc.), but I would like to
>
>>>>>>> have a
>
>>>>>>> confirmation - or a correction if I'm wrong - of the following:
>
>>>>>>> >
>
>>>>>>> > Public parameterized method which are impossible to implement
>
>>>>>>> without unprovable "unsafe cast" warnings, and which are known to
>
>>>>>>> break
>
>>>>>>> parameterized type safety, are unacceptable.
>
>>>>>>> > There is nothing wrong in using the <?> wildcard in a return
>
>>>>>>> value if the actual type can not be expressed by the Java
>
>>>>>>> parameterized
>
>>>>>>> type syntax.
>
>>>>>>> >
>
>>>>>>> >
>
>>>>>>> > Regards,
>
>>>>>>> >
>
>>>>>>> > Martin
>
>>>>>>> >
>
>>>>>>>
>
>>>>>>> It could be worth adding, some JSR members who considered the
>
>>>>>>> wildcard a bad or outdated practice already work with the JDK team,
>
>>>>>>> at
>
>>>>>>> least via AdoptOpenJDK (@Otavio, what have you done there so far if
>
>>>>>>> anything?;-)
>
>>>>>>>
>
>>>>>>> Regards,
>
>>>>>>> Werner
>
>>>>>>>
>
>>>>>>
>
>>>>>>
>
>>>