Use Advanced Search to search the entire archive.
Re: Email proposal to the core-libs-dev@openjdk.java.net
- From: Otávio Gonçalves de Santana <
>
- To:
- Subject: Re: Email proposal to the
- Date: Sun, 19 Oct 2014 22:28:33 -0200
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
>
>>>>>>
>
>>>>>
>
>>>>>
>
>>