Proposal for Property Accessors

[Jochen Theodorou]

To drive the language list down there further I name the Groovy 
variant... fully aware that it is not likely something for Java at all. 
In Groovy we do:

class Egg {
   int color
}

This will generate a getColor and a setColor method, just like you 
expect from the Java Bean Spec. You can still write those methods, if 
you want, then the method is taken instead of the generated version

In code you can access the property like this: egg.color

so exactly the same as a field. And that is actually a problem, since 
you now have to make a difference between a field and a property. 
Because sometimes you don't want to call the getter or setter, sometimes 
you want to write directly into the field, since getter or setter may 
contain additional code. If you would not need additional code, you 
could simply go with fields.

If you go the route with user getter/setter and generated getter/setter 
at the same time, you get problems with knowing when you need what. 
Another problem are indexed properties. It is no problem in Groovy to 
have a property return a field, but getter/setter with the index as 
parameter look in Groovy like method calls. So they would either need 
another syntax or they are not supported... which is what Groovy does in 
the end. You can still call them as methods, but if you want to do 
egg.color[1], you need a color property returning an array.

As for a special bytecode instruction... normally invokedynamic is 
powerfull enough to resolve such things on the bytecode level. I see the 
problem much more on the syntax side.

Recognizing what a property is from existing Java code is also an issue. 
Thanks to our approach, if there are getter/setter, then they are 
properties. A compiler then can for example simply call the getter and 
setter like a normal method... really no special need for a special 
instruction just for a static compiler. At least that is what the Groovy 
static compiler is doing.

bye Jochen

Am 06.01.2013 10:43, schrieb Noctarius:
[...]
>>>>>> 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.
[...]
>>> Here's the C# approach:
>>> public class Egg {
>>>     private int color;
>>>
>>>     public int color {
>>>       get
>>>       {
>>>         return this.color;
>>>       }
>>>       set
>>>       {
>>>         this.color = value;
>>>       }
>>>     }
>>> }
>>
>> yes, and with an AS3-like approach:
>> public function get color():int { return this.color; }
>> public function set color(value:int):void { this.color=value; }
>>
>
> The problem is, I see no clear standard what makes sense to say
> "yeah let's gonna go that way".
>
> AS3:
> public function get color():int { ... }
> public function set color(value:int):void { ... }
>
> C#:
> private int color;
> public int color {
>    get {
>      ...
>    }
>    set {
>      ...
>    }
> }
>
> Ruby:
> attr_accessor :color
>
> C++:
> Well no real kind of property but could be emulated using operator
> overloading
>
> MS C++:
> __declspec(property(get = getprop, put = putprop)) int the_prop;
>
> D:
> private int m_color;
> @property public int color() { ... }
> @property public int color(int value) { ... }
>
> Delphi had some way but I don't remeber it (thanks to god I finally
> forgot about Delphi).
>
> JS:
> color: {
>    get: function() { ... },
>    set: function(value) { ... }
> }
>
> Objective-C:
> @property int *color;
> @synthesize color;
>
> PHP:
> function __get($property) { ... }
> function __set($property, $value) { ... }
>
> I guess there are a lot more kinds of properties syntax out there
> and it neither seem to have a clean standard and nor that anyone of
> the above examples is better then the other. The interesting fact
> is, that AS and JS are totally different even though both are ECMA
> Script derived. JS in this case is more similar to C# (or other way
> round ;-)).
>
>> now, if one takes the above, and converts it to Java-like declarations,
>> one gets:
>> public int get color() { return this.color; }
>> public void set color(int value) { this.color=value; }
>>
>> more-or-less...
>>
>>
>> at least in my language, getters/setters are internally mostly just
>> normal methods, so the above would internally become something more like:
>> public int _get_color() { return this.color; }
>> public void _set_color(int value) { this.color=value; }
>>
>> with index properties having names like "_getindex_" and "_setindex_".
>>
>> actually, more-so, they are currently handled as a parser-hack.
>>
>>
>> the other part of the process is basically just handling getting/setting
>> them differently.
>> the closest direct JVM analogue of the mechanism would probably be the
>> "invokevirtual" instruction.
>>
>> granted, in my VM, these are implemented as a special case of the field
>> load/store instructions, which more work by detecting the presence of
>> the getter/setter method, and using special logic to call these methods
>> instead.
>>
>> this would be analogous in the JVM to detecting and handling this
>> special-case in the JIT.
>>
>>
>> the major functional difference being in my case that my VM uses
>> threaded-code (execution as a sequence of calls into C functions) as a
>> kind of cheaper/lazier/slower alternative to a JIT, with this
>> translation taking place the first time a given method is called (in my
>> VM, it is effectively "frozen" after this point). (side note: while
>> threaded-code is somewhat slower than JIT compiled code, it has the
>> advantage that it is easier to implement and maintain, as it avoids much
>> of the hairy compiler logic and piles of target-specific ASM code...).
>> (though, it is also possible to mix natively generated code and calls
>> back into VM functions, but either way...).
>>
>>
>> or such...
>>
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>