Parameter reflection without MethodParameters attribute

[Remi Forax]

On 12/08/2012 02:19 AM, Joseph Darcy wrote:
> I agree; I think the API would be quite inconvenient to use if the 
> client had to test the result for null and then make up their own 
> parameter name.
>
> -Joe

for what it worth, I agree too.

Rémi

>
> On 12/7/2012 5:11 PM, Mike Duigou wrote:
>> There's slightly less value informationally to arg0, arg1 etc but 
>> it's still useful. I'd rather refer to arg0 than "the third int 
>> parameter". If I imagine I was looking at System.arrayCopy prototype 
>> I'd prefer to see arg0, etc than just the type names. Seeing the real 
>> names would, of course, be even better because methods like arrayCopy 
>> are inscrutable without knowing the parameter names. Just looking at 
>> the types doesn't tell you enough.
>>
>> So, synthesized flag yes, non-null name yes please.
>>
>> Mike
>>
>> On Dec 7 2012, at 16:13 , Paul Benedict wrote:
>>
>>> Always returning Parameter objects seems like a good idea to me --
>>> whether the information is available or not. However, if it's being
>>> manufactured (as the parameter names are absent), I question the
>>> utility of coming up with make-believe names.
>>>
>>> I would opt to have a Parameter object have a null name and a flag
>>> that says it's being synthesized.
>>>
>>> Paul
>>>
>>> On Fri, Dec 7, 2012 at 6:06 PM, Alex Buckley 
>>> <alex.buckley at oracle.com> wrote:
>>>> On 12/6/2012 5:32 PM, Joseph Darcy wrote:
>>>>> Alternatively, I think it is friendlier for the user for the
>>>>> implementation of Executable.getParameters() to manufacture 
>>>>> placeholder
>>>>> names if none are available, "arg0", "arg1", etc.
>>>>
>>>> I concede that Executable.getParameters() can _always_ return somewhat
>>>> useful results, namely Parameter objects which expose annotations (if
>>>> present) and class/type info. Along with placeholder names/values, 
>>>> this is a
>>>> good argument for always getting non-null Parameter values from
>>>> getParameters().
>>>>
>>>> At the same time, a reflective client might want to know if the 
>>>> Parameter
>>>> objects it's getting are made of placeholders or made from a real
>>>> MethodParameters attribute. Executable.hasEnhancedMetadata() is a
>>>> possibility, but it goes toward "quality of service" (i.e. are names
>>>> normative?) which is out of scope for SE 8.
>>>>
>>>> So for now, let's always return Parameter objects and synthesize
>>>> placeholders as you suggest. I've updated the spec (section 2.2).
>>>>
>>>> Alex
>