On 1/5/2013 12: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).
possibly, but whether or not this is the best way to handle this is
debatable.
sometimes, a recompile is a justifiable requirement.
>> 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.
yes, but I think my syntax would probably be a little more consistent
with Java in general...
it is also a little more like that of some other languages which have
properties (it was more written as a more Java-ified version of the
ActionScript syntax).
alternatively, a person could just directly rip off C#'s syntax as well.
both are preferable IMO to devising new/unfamiliar syntax.
this is partly as existing languages have already set precedent for what
the syntax may look like.
>> 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
>>
>
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
