Proposal for Property Accessors

[Noctarius]

Am 05.01.2013 22:47, schrieb 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; }
> 

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
>