@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