Review request JDK-8007619: Add support for deprecated properties of RegExp constructor

[Hannes Wallnoefer]

After talking to Sundar some more we agreed that this patch is fine 
until the issues with nasgen for supporting actual properties are 
solved. I've filed a bug for that: 
https://jbs.oracle.com/bugs/browse/JDK-8007627

Hannes

Am 2013-02-06 11:50, schrieb A. Sundararajan:
> $1-$9 properties change b/w invocations. For eg. $5 may not exist 
> after an exec call - if there are only 4 matches.
>
> Also, adding as properties implies fixed cost - you pay regardless of 
> using those deprecated properties or not - i.e., propertyMap gets 
> added entries. With __noSuchProperty__ hook, this is called only when 
> user really uses it.
>
> On avoiding another "internal" property: we may expect constructor to 
> be of specific type and use package private field or something -- but 
> then we can't access NativeRegExp$Constructor at compile time as it is 
> generated by nasgen :-(
>
> -Sundar
>
> On Wednesday 06 February 2013 04:13 PM, Hannes Wallnoefer wrote:
>> To be honest this looks a bit hacky to me. The properties on the 
>> constructor are configurable and writable (since they are technically 
>> not defined), and the __last_regexp_match__ property leaks out to the 
>> script.
>>
>> I think ideally we should support getters on the constructor (which I 
>> think we currently do not):
>>
>>     @Getter(where = Where.CONSTRUCTOR)
>>     public static Object lastMatch(Object self) {
>>         ...
>>     }
>>
>> And maybe we could think of a way to let the getter know what to 
>> return without using a public property on the constructor?
>>
>> Hannes
>>
>> Am 2013-02-06 09:06, schrieb A. Sundararajan:
>>> Please review http://cr.openjdk.java.net/~sundar/8007619/
>>>
>>> Thanks,
>>> -Sundar
>>
>