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).
>
> but, how about the syntax: public int get color() { return
> iColor; } public void set color(int value) { iColor=value; }
> public int get[](int idx) { return array[idx]; } public void
> set[](int idx, int value) { array[idx]=value; }
>
The idea about the proposed syntax was to be minimalistic, it
should prevent you from writing getters and setters which are just
a big bunch of boilerplate codebase.
> as-before, with them just converting to normal methods
> internally (with slightly mangled names). when a person tries
> to access a field, the compiler may observe that the actual
> field does not exist or is not accessible, mangle the name
> (into the form used by a property), and then see that the
> property exists, and use this.
>
Thanks for your response :-)
Chris
>
>> Cheers Chris
>>
>> Am 05.01.2013 15:20, schrieb Noctarius:
>>> Hey Yesterday I started a discussion (not yet very active)
>>> on the java.net forums about adding Property Accessors to
>>> the Java language.
>>>
>>> Currently I'm still not totally convinced on how to do all
>>> that for example accessors for array index access but I'm
>>> pretty sure there are good ideas out there in other's
>>> heads.
>>>
>>> The topic is not totally correct at the davinci ml but
>>> since this would need a bit of implementation details in
>>> the JVM I thought that maybe some of you guys are
>>> interested in the general idea. I would be happy to see
>>> some of you contributing ideas and maybe help on
>>> prototyping such an implementation.
>>>
>>> For me it would be the biggest problem to make this idea in
>>> an OpenJDK project or JSR since I never did anything
>>> similar but I hope someone can help with this as well.
>>>
>>> So I'll close in hope that there are more people out there
>>> thinking about similar projects which can merge or see a
>>> bigger potential in my thoughts.
>>>
>>> The link to the discussion:
>>> http://www.java.net/forum/topic/jcp/general-jsr-discussion/properties-proposal
>>>
>>>
>>>
Thanks from Germany Christoph
>>> _______________________________________________ mlvm-dev
>>> mailing list mlvm-dev@openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>
>>
>
> _______________________________________________ mlvm-dev
> mailing list mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
--
##############################
# A Digital's Life #
##############################
Nickname: Noctarius
Location: Germany
Meet me at:
Ohloh: http://www.ohloh.net/accounts/noctarius
Web: http://www.noctarius.com
XMPP/Jabber: noctar...@jabber.ccc.de
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
