Parameter reflection without MethodParameters attribute

[Alex Buckley]

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