Properties

[Miles]

Nick Sabalausky wrote:
> This proposal doesn't prevent any of that. Suppose our syntax was like in 
> the example above. I would still be able to do something like this:
> 
> ---------------
> protected int _var;
> public property char[] var
> {
>     // char[] internalValue is still defined,
>     // but gets optimized away since it's never used.
> 
>     get { return ToString(_var); }
>     set { _var = ToInt($); }
> }
> ---------------

The problem I see with this is that it complicates the implementation of
properties. Properties are just collections of delegates, perhaps even
optimized to contain only a single frame pointer for multiple function
pointers. Properties may appear in contexts where you can't have member
variables (e.g., interfaces).

> ---------------
> class Foo
> {
>     public property int myProp
>     {
>         get { return internalValue; }
>         set { internalValue = $; }
>     }
> 
>     public bar()
>     {
>         Stdout.formatln("{}", myProp.internalValue);
>     }
> }
> ---------------

Won't work, not like that. For the compiler, that is difficult to
distinguish from calling the getter for myProp (that returns an int),
and trying to access a member variable called "internalValue" from that
int instance.

The compiler could provide some syntax to disambiguate property's
members from it's value's members. Perhaps:

	property(myProp).internalValue;

In this case, property(...) tells the compiler to handle the argument as
the property itself, without calling the getter. But requiring that
syntax just sucks. I find it better to have the value in another variable.