Proposal for Property Accessors

[Noctarius]

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.

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

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