@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