Possible @property compromise

Rob T alanb at ucora.com
Tue Jan 29 18:15:05 PST 2013


On Wednesday, 30 January 2013 at 01:40:52 UTC, TommiT wrote:
> On Wednesday, 30 January 2013 at 00:25:41 UTC, Jonathan M Davis 
> wrote:
>> On Wednesday, January 30, 2013 00:55:13 Rob T wrote:
>>> [..]
>>> You know a lot more about implementing compiler magic than I 
>>> do, so I'll ask you if you think the effort is doable enough
>>> to justify having property functions that can act like a
>>> drop in replacement for existing variables?
>>
>> I believe that two main things are needed: [..]
>
> I always thought that having public member variables is a bad 
> style of programming because of the lack of encapsulation. So, 
> if there's a language feature that enables you to write public 
> member variables, and later on, replace them with property 
> functions, wouldn't that mean that the language is encouraging 
> this particular kind of bad style of programming?

Well, the main reason why this was bad convention, is because the 
"." operator conceptually returns by reference, so you are 
operating directly on the encapsulated variable with no 
possibility of oversight through the encapsulation.

The @property method will restrict variable usage to non-ref and 
non-pointer uses only, which is a form of encapsulation through 
the "." operator, and it can later be replaced with a function 
call if required.

Even with @property restrictions, I still don't think it will 
work as expected. For example, if the variable is a struct, then 
you have to disallow operations on the struct from outside.

Example:

struct Y { int a; }

struct X{ @property Y y; }

X x;

x.y.a = 4; // <- this has to be illegal!

Reason?

struct X{

   Y _y;

   @property Y y{ return _y; }

}

// this won't change _y as it did before.
x.y.a = 4;

I figure if we're going to do something about properties, we may 
as well do something much more compelling and re-invent the 
property rather than attempt to partially emulate variables just 
because someone was in a hurry and left their encapsulated 
variables public and used them directly outside the struct or 
class.

--rt


More information about the Digitalmars-d mailing list