Properties sugestion.

[Chad J]

Jb wrote:
> class Foo
> {
> 
>   int _foo;
> 
>   property Bar
>   {
>       void opAssign(int i) { _foo = i;}
>       int opRValue() { return _foo; }
>       int OpPostInc() { _foo++; return _foo-1; }
>   }
> 
>   property Baz { void opRValue() { return _foo*2; }  }
> 
> }
> 
> I'll admit i didnt follow all of the points in the original thread but it 
> got me thinking that why not re-use operator overloading syntax to define 
> the operators that can (or cant) be used with a property.  Perhaps require 
> that the correct one be implemented when the property is used as an lvalue? 
> Just those problematic operators that cause ambiguity could just cause a 
> compiler error if used when not implemented.
> 
> If you want to get a delegate to the function you could simply address the 
> operator function...
> 
> &Foo.Width.opAssign;
> 
> 
> 

With all of the operator overloads, this is going to get way to verbose 
every time someone wants to write a property.  Mixin templates could 
help, but would still be unnecessary.  lvalueness is a sane default 
behavior.  It's sort of like why D doesn't have C/C++'s -> operator, no 
one would want to write "auto temp = foo(); temp++;" where foo is the 
expanded form of a property.  They almost always mean "auto temp = 
foo(); foo( temp + 1);".  It would be nice though, to allow this kind of 
suggested syntax as a means of overriding default behavior.

I'll be trying out some template stuff, the kind of thing that was 
happening at the end of the original thread.  Perhaps this problem can 
simply be converted to a problem of lacking opDot, though that is 
somewhat unlikely.  If that doesn't pan out just perfectly, then I'll 
also be looking at python and delphi properties.