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

Rob T alanb at ucora.com
Wed Feb 20 11:41:24 PST 2013


Has anyone really tried to use @property assuming the optional 
assignment syntax will be depreciated? I have.

The results I'm getting is a ton of @property tags in my structs 
and classes, much more than I had expected. In one struct, almost 
all the functions are tagged @property. I know I can wrap them in 
@property: or @property{} but the side effect of that is that I 
must be aware of where I'm locating all of the property functions 
vs the non-property functions.

In the case where most of my functions get tagged, it's a pain to 
be forced to locate them inside the wrapper.

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.

The reality is that I often don't know if I'll be using one 
syntax over the other until usage experience is gained and the 
usage context determines the answer. I may even want to use both 
forms depending on the use context.

So I'm seriously considering deleting all of the @property tags 
already added and to stop inserting new tags, because even if 
they somehow can add value, there's definitely far too much 
clutter involved causing the opposite of "value". I just don't 
want to have to think about something that has no clear answer 
until later down the road (if at all).

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.

My two cents, thanks for listening.

--rt


More information about the Digitalmars-d mailing list