Properties

[Nick Sabalausky]

"Miles" <_______ at _______.____> wrote in message 
news:gk68q1$19g1$1 at digitalmars.com...
> Chad J wrote:
>> I actually like the idea.
>>
>> (...)
>>
>> int nTimesVarRead = 0;
>>
>> public property int var
>> {
>>     get
>>     {
>>         nTimesVarRead++;
>>         return internalValue;
>>     }
>>
>>     set { internalValue = $; }
>> }
>
> That defeats one of the purposes of properties. A property is usually an
> accessor for some member variable. You have two concepts: the property
> and the member variable; they MUST be declared separately, since they
> may have different attributes.
>
> For example, the underlying member variable may have any of public,
> protected or private visibility, while the property may also have any of
> public, protected or private visibility. Usually, the member variable is
> either protected or private, while the property is either public or
> protected.
>
> Also, the class itself, and any inner scopes, may want to access the
> underlying member variable directly, without going through the property
> accessors.
>

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($); }
}
---------------

Also, we could say that the "internalValue" attribute of "private" (or 
protected, maybe we could have a way to optionally allow it to be protected) 
means "private to the class that contains the property" instead of "only 
accessible to the code within the property definition". Then we could do:

---------------
class Foo
{
    public property int myProp
    {
        get { return internalValue; }
        set { internalValue = $; }
    }

    public bar()
    {
        Stdout.formatln("{}", myProp.internalValue);
    }
}
---------------

Although I think I'm starting to really like the syntax being developed in 
another branch of this thread...(also I think I'm going to expand it a 
little):

---------------
module foo;
class Foo
{
    public property int myProp
    {
        get { return this; }
        set { this = this.new; }
    }

    // Shorthand for the same trivial accessors in "myProp"
    public property int myShorthandProp
    { get; set; }

    public property int readOnlyProp
    {
        get { return 7; }
    }

    public property int writeOnlyProp
    { set; }

    public property int polysemousProp
    {
        set { this = this.new; }
        get { return this; }

        set char[] { this = StringToInt(this.new); }

        // If we ever got overload-on-return-value
        get char[] { return IntToString(this); }
    }

    private property int privateProp
    { get; set; }

    public property int anotherProp
    {
        /* Change access attribute of internal value, default could be 
either protected or private. This doesn't affect Foo's ability to see or not 
see the internal value. This only affects Foo subclasses and code outside 
the module. */
        protected this;

        get;

        // Foo can access anotherProp's setter, but everything else sees 
anotherProp as read-only.
        private set;
    }

    public bar()
    {
        auto a = myProp; // Ok, uses getter
        auto b = myProp.this; // Ok, internal value
        auto c = privateProp; // Ok, uses getter
        auto d = privateProp.this; // Ok, internal value
        auto e = writeOnlyProp; // Error: no getter
        auto f = writeOnlyProp.this; // Ok, since we're inside Foo
    }
}

module main;
void main()
{
    auto foo = new Foo();

    auto a = myProp; // Ok, uses getter
    auto b = myProp.this; // Error: internal value is private to Foo
    auto c = privateProp; // Error: privateProp is private
    auto c = privateProp.this; // Error: privateProp is private
    auto e = writeOnlyProp; // Error: no getter
    auto f = writeOnlyProp.this; // Error: internal value is private to Foo
}
---------------

>> Perhaps, since the compiler knows the name of the property, the name of
>> the generated internal value could just be the name of the property:
>>
>> public property int var
>> {
>>     get { return var; }
>>     set { var = $; }
>> }
>
> That is the question... the property is public, but var is private or
> protected? How does the class access var without triggering the property
> accessors?

See above.