Am 06.01.2013 11:22, schrieb 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.
>
In that case I would suggest to write a special method not routing
through the getter/setter since those would only be used externally
(not internally in the defining class).
In (I guess) 99% of all cases you want the getters / setters to be
called.
> 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.
>
For indexed fields I thought about (for one-dimensional arrays) to be:
property int[] foo {
(index, value) -> { foo[index] = value; }
(index) -> { foo[index]; }
}
For multi-dimensional arrays it's not so handy and I stuck at what a
nice syntax would look like but maybe something like this:
property int[][][] foo {
(indexes, value) -> { // indexes itself is an array length
//of given indexes
...
}
}
But as I said, currently not sure what a nice syntax would be, maybe
in that case there is no nice way - not sure.
> 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@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
