@property - take it behind the woodshed and shoot it?

Johannes Pfau nospam at example.com
Fri Jan 25 12:16:06 PST 2013


Am Fri, 25 Jan 2013 14:59:58 -0500
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

> I agree with all of the above. There has been a fair amount of 
> rationalization and appeal to emotion on all sides. It would be great
> to get back to reason and clearly compartmentalize objective
> arguments (of which there have been a few very profound ones) and
> personal preference.

Do that on this wiki page:
http://wiki.dlang.org/Property_Discussion_Wrap-up

> There's more "@property" to be seen with "save" and "back".
> Subjectively that just didn't work well for me. It adds clutter to an
> otherwise simple and straightforward API, and penalizes usage for
> benefits that I could never reap.

I think it actually makes sense. I even tried writing ranges for
std.digest where front was not a property but a field and was
surprised it didn't work.

(isInputRange shouldn't check for property. It
should check for "can be used like a field" which means
field+property.).

> I understand how some people are
> glad to put that in everywhere, and find meaning in requiring parens
> with popFront and popBack but not the others. Yet for me it was
> liberating (see 1 above too) I could just write "r.popFront" without
> the parens and have it do its deed. It is the right semantics for a
> simple syntax.

Please read the wiki page. popFront or popFront() is orthogonal to the
property discussion.

> 
> 3. Whatever we do going forward should be _simple_ but not
> _simplistic_. Right now it's easy to forget that we're all close to
> the subject. We have it in working memory (at least it's what I think
> about all the time) and any incremental complexity is an easy cost to
> absorb intellectually.
> 
> But when we need to teach this to newcomers or even approach it again 
> with a "cold cache", any undue complexity will be jarring.

Wiki page, wiki page ;-)
> 
> 4. Whether we like it or not, backward compatibility is an issue. The 
> parens or no parens aspect upon a function call is too ubiquitous to 
> write off as an obscure circumstance. So I don't think the obscurity 
> argument applies.
> 
> Granted, there are several ways to approach the compatibility issue,
> all with their specific tradeoffs. All I'm saying is that careful 
> considerations of compatibility must be integral to whatever we do
> about this.

The approach described on the wiki does break some code, but that code
shouldn't compile anyway: @property functions with wrong number of
arguments and similar stuff.

Only controversial thing is taking the address of a property, but I
can't think of a solution which would work well with generic code so
I'd just say forbid that.
> 
> 5. This is a matter in which reasonable people may disagree. For
> better or worse Walter and to a lesser extent myself are in the
> position to decide. We're doing the best to gather, mind, and
> integrate opinions and suggestions but clearly no decision that would
> please everyone.

Would be nice if the arguments for the final decision are added to the
wiki page :-)



More information about the Digitalmars-d mailing list