@property as proposed in various DIPs, my attempted use and what I think of it

Mike Parker aldacron at gmail.com
Thu Feb 21 02:57:09 PST 2013


On Wednesday, 20 February 2013 at 19:41:25 UTC, Rob T wrote:

>
> In an effort to reduce the use of @property, I have to guess if 
> I'm really going to use a given function with the assignment 
> syntax or not, but that's something I prefer not to be 
> constantly thinking about, so the tendency is to defer the 
> question and simply avoid using @property completely.
>

For me, there's no guessing. Either something is a property, or 
it isn't. Period. If I have a class or struct member that is 
read-only, I use a property to access it. If I need to do some 
bookkeeping when a member is read or written to, I use 
properties. If I'm using a sort of facade, where a class is 
making use of another class or structure internally and I want to 
expose some of the internals, then I use a property. Example:

struct FooData {...}

class Foo() {
    private FooData _data;
    private this(FooData data) { _data = data; }

    public static createFoo() { return new 
Foo(loadFooDataFromSomewhere())

    int bar() @property { return _data.bar; }
}

It's a very clear, straightforward concept for me. createFoo is 
obviously not a property, but anywhere I would want to use a 
getBar(), I will instead prefer to use a property.

> My attempted use of @property indicates that most people will 
> simply not use it and instead use the regular function form - 
> it's much easier that way. You may switch to @property for the 
> rare situations where an exposed struct/class variable is later 
> changed into function form, but for me anyway using exposed 
> variables in production code is an extreme rarity - I only do 
> that with experimental throw away code.

This is what makes no sense to me. And I think a sample size of 1 
is not enough to extrapolate how "most people" will or will not 
use @property. I use it throughout my D code quite satisfactorily.


More information about the Digitalmars-d mailing list