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.
