Fixing D's Properties

[Chad J]

Jb wrote:
> "BCS" <ao at pathlink.com> wrote in message 
> news:ce0a3343d64a8c9afeb721a0ab0 at news.digitalmars.com...
>> Reply to Ender,
>>
>>> int getX(){ return x;}
>>> void setX(int i){x = i;}
>>> property int X(&getX, &setX);
>>>
>>> the problem is that unlike in python we cannot use keywords to set
>>> paramaters so some syntax would have to be made for write only
>>> properties, maybe if we used inout instead of property:
>>>
>> property int X(void, &setX);
>> property int Y(&getY, void);
>>
>> ??
>>
>> I'm not sure I like this more than what we have, but it does leave open 
>> getting at the functions which I like. It might grow on me.
> 
> Delphi does this.
> 
> _foo int;
> 
> int getFoo() { return _foo; };
> vood setFoo(i: integer) {_foo = i; );
> 
> any of the following are valid...
> 
> property int foo : read getFoo write setFoo;
> property int foo : read _foo write _foo;
> property int foo : read getFoo write _foo;
> property int foo : read _foo;
> ect..
> 
> I converted the Delphi syntax to be more D like, and its just offered for 
> reference, not a proposal as such.
> 
> So the property specifies either or both read / write, of which either or 
> both can be direct acess to the field or a proxy function. The proxy 
> functions can be virtual and so can be overriden in subclasses. So you get 
> read only, write only, read/write, direct field acess, static function, or 
> virtual function. And you can still expose the function if you want.
> 
> jb
> 

I like where all of this is going.

Then the solution becomes one which allows properties to be treated 
exactly* as members on the using side, yet allows the underlying 
functions to be used as well.  So BCS, would you be willing to settle 
for such a solution?

* I realize we may have to settle for properties being "close enough" to 
members, due to addressing.