Parameter reflection without MethodParameters attribute

[Eamonn McManus]

Perhaps the synthesized names should have $ in them (e.g. arg$0 or $0), as
is done for synthesized names elsewhere.

Éamonn



2012/12/10 Alex Buckley <alex.buckley at oracle.com>

> 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
>>>>>>
>>>>>
>>>
>>