Proposal for Property Accessors

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

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

Rémi