"Miles" <____...@_______.____> wrote in message
news:gk68q1$19g...@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.
