Parameter reflection without MethodParameters attribute

[Alex Buckley]

Thanks all for comments. We're going to proceed on the basis of the 
current spec. (Executable.getParameters() always returns Parameter 
objects, synthesizing them if necessary, and no flag method to tell 
whether they were synthesized.)

Alex

On 12/8/2012 4:52 AM, Remi Forax wrote:
> 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
>>
>