Parameter reflection without MethodParameters attribute

[Alex Buckley]

Actually, it's not quite so clean, since $ in nested type names is 
_synthesized_ on account of being specified in JLS 13.1. Of course 13.1 
is rather oddball since it's a compiler spec not a language spec. In any 
case, $ is by and large for synthetic names.

Alex

On 12/10/2012 3:03 PM, Alex Buckley wrote:
> $ has traditionally been used in _synthetic_ names (i.e. of
> compiler-specific artifacts) whereas the parameter names in question are
> _synthesized_ (i.e. the spec mandates their existence and format). As
> Joe said, the language model already has a good convention ("argI") for
> synthesized parameter names.
>
> Alex
>
> On 12/10/2012 2:53 PM, Paul Benedict wrote:
>> Eamonn, it's interesting. However, since Alex doesn't want a flag to
>> tell whether they were synthesized, the $ could provide a leak in that
>> information wall.
>>
>> Paul
>>
>> On Mon, Dec 10, 2012 at 4:51 PM, Eamonn McManus <eamonn at mcmanus.net>
>> wrote:
>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>