Am 05.01.2013 20:44, schrieb BGB:
> 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.
The proposal is derived from C# syntax with mixed in Lambdas. So you
would prefer to split member and getter/setter definition like in C#
or AS3?
Here's the C# approach:
public class Egg {
private int color;
public int color {
get
{
return this.color;
}
set
{
this.color = value;
}
}
}
>
> 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
>
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
