Proposal for Property Accessors

[Noctarius]

Am 05.01.2013 21:03, schrieb Remi Forax:
> On 01/05/2013 07:53 PM, Noctarius wrote:
>> Am 05.01.2013 19:41, schrieb Remi Forax:
>>> On 01/05/2013 07:37 PM, Noctarius wrote:
>>>> Am 05.01.2013 19:15, schrieb BGB:
>>>>> On 1/5/2013 10:17 AM, Noctarius wrote:
>>>>>> Ok I took some time to make a deeper introduction in
>>>>>> what I imagine to do: 
>>>>>> https://www.sourceprojects.org/default/2013/01/05/1357395720000.html
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>>> 
As mentioned before it would be great if someone is interested in
>>>>>> the topic and wants to help.
>>>>> well, I guess this forum is more for JVM level stuff,
>>>>> whereas all this is more a Java compiler level feature,
>>>>> but oh well...
>>>>> 
>>>> But this feature would need JVM level support to make old
>>>> code working. That's the most important feature from my
>>>> point of view - you can just make the old public field a
>>>> property and old external code does not needs to be
>>>> recompiled. One idea would be to relocate the xload
>>>> bytecode to the property accessor (maybe there would be a
>>>> better way).
>>> There is a better way, the load should be an invokedynamic
>>> so it can be wired to a getter or a field access depending
>>> on the implementation.
>> By "relocate the xload bytecode" i meant to exchange it with
>> an invokedynamic call just on loadtime of a class. The idea
>> would be to flag the members of type property and exchange
>> them. I want to prevent recompile of depending code.
> 
> You can do that with 'invokedynamic' and not at load time but
> the first time the instruction is called, note the name is
> invokedynamic and not invokevirtual.

But that needs to be backed in the bytecode. See the other answer below.

>> 
>>> Now, the real question is what problem do you want to solve
>>> exactly ?
>> As I've written in the blog article is to unify the access
>> to members. As an addition you'll get some kind of syntactic
>> sugar which prevents you from writing all that getter /
>> setter stuff (yeah I know Eclipse / IntelliJ / ... can
>> generate them for you) but the main reason is to have a
>> possibility to "update" and strongen old codebasis without
>> breaking compatibility - quite similar to the idea of the
>> virtual extension methods.
> 
> I think I prefer a more general mechanism that ask javac to
> replace all access to fields (or methods) for a given class,
> insert an invokedynamic instead and let you specifies the
> bootstrap method in Java code.
> 
> With that, you have properties, proxy, interceptor, AOP, and
> with a little effort method_not_found.

Yeah I totally agree but I'm not sure if you should break the
backward compatibility that extremely. Your the guys with more
experience in bringing new features to Java so I would rely on
your opinion in case of this.

> Rémi
> 
> _______________________________________________ mlvm-dev
> mailing list mlvm-dev at openjdk.java.net 
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>