RFR(S): 8143410: augment pseudo-code descriptions in MethodHandles API
Michael Haupt
michael.haupt at oracle.com
Tue Feb 23 08:15:36 UTC 2016
Hi Paul,
thanks - all right; I'll consider using "and" rather than "/" and push the result.
Best,
Michael
> Am 23.02.2016 um 09:13 schrieb Paul Sandoz <paul.sandoz at oracle.com>:
>
>>
>> On 23 Feb 2016, at 07:39, Michael Haupt <michael.haupt at oracle.com> wrote:
>>
>> Hi Paul,
>>
>> thank you. I'm holding off on pushing; a new webrev is at http://cr.openjdk.java.net/~mhaupt/8143410/webrev.01. See below for two specific comments.
>>
>>> Am 22.02.2016 um 21:45 schrieb Paul Sandoz <paul.sandoz at oracle.com>:
>>>> Webrev: http://cr.openjdk.java.net/~mhaupt/8143410/webrev.00
>>>>
>>>> The change documents the type variables used in the pseudo-code in the API documentation of the following methods in MethodHandles: catchException(), collectArguments(), filterArguments(), filterReturnValue(), foldArguments(), and guardWithTest().
>>>
>>> Just minor stuff:
>>>
>>> 2642 * <p>Here is pseudocode for the resulting adapter. In the code, {@code T}
>>> 2643 * denotes the return type of both the {@code target} and resulting adapter.
>>> 2644 * {@code P}/{@code p} and {@code B}/{@code b} represent the types / values
>>> 2645 * of the parameters / arguments that precede / follow the filter position
>>> 2646 * {@code pos}. {@code A[i]}/{@code a[i]} stand for the types / values of
>>>
>>>
>>> "precede / follow ..." -> "proceed and follow …, respectively” ? like that for the last modified method doc.
>>
>> That's "precede" as in "coming before in the list". "Proceed" wouldn't make sense in this context. Or did you mean "... respectively" should be appended? (In the webrev, I've applied the latter.)
>>
>
> Oops, I typed “proceed and follow …, respectively” but meant “precede and follow…, respectively” :-)
>
> Tis a minor thing, I find the use of “and” rather than “/“ flows better, given the already heavy use of ‘/‘.
>
>
>>> 2884 * }</pre></blockquote>
>>> 2885 * <p>Here is pseudocode for the resulting adapter. In the code, {@code V}
>>> 2886 * represents the result type of the {@code target}; {@code T}, that of the
>>> 2887 * {@code filter}; and {@code A}/{@code a}, the types / values of the
>>> 2888 * parameters / arguments of the {@code target} as well as the resulting
>>> 2889 * adapter.
>>> 2890 * <blockquote><pre>{@code
>>> 2891 * V target(A...);
>>> 2892 * T filter(V);
>>>
>>>
>>> Should target return a type of T, and filter V for consistency with the other pseudocode examples? That might be more changes than you wanna apply in this case :-)
>>
>> You're right, the naming should be consistent. I've applied this throughout.
>>
>
> Ok.
>
> Paul.
--
<http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany
ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
<http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
More information about the core-libs-dev
mailing list