Proposal for Property Accessors

[BGB]

On 1/5/2013 2:20 PM, Noctarius wrote:
> 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?

for what similarity it had, it also introduced some "unconventional" 
elements.

> 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; }

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...