On 1/25/13 12:17 PM, Rob T wrote:
On Friday, 25 January 2013 at 16:43:45 UTC, Jesse Phillips wrote:
[...]
That said many that want @property, want optional parens to die, as
shown by your side comment that follows.
I think that observation pins the whole debate down, and it's an
incredible amount of debate for something that boils down little more
than personal taste. We don't even need property-like behavior, it's not
that important. Meanwhile really serious problems exist that are not
being attended to.
The concept of a property works perfectly fine without explicit
@property enforcement (except for perhaps an edge case or two that can
be corrected). When I started with D, the TDPL told me that I had to put
@property in, and it was actually a relief to discover that I did not
have to do that. It's a waste of time, and more than half the time I
could not decide if I wanted property-like behavior or not, so the lack
of enforcement was a plus for me.
If the default behavior is optional parens plus no @property
enforcement, i.e., the current behavior, then for the people who want to
change the default behavior need to specify @property and we implement
enforcement for those situations. However, for the remaining functions,
the property behavior is optional and not enforced, so some means such
as the @function proposal will be needed to enforce the traditional
c-like function call syntax.
But is there any real need for the extra complications of implementing
property and c-style function call enforcement? This is D and there's no
law that states that D must behave exactly like C.
I think Walters proposal to shoot @property is perfectly sound. Get rid
of it, fix the edge cases, and move on to solving the problems that
matter a whole lot more than this one.
If Walter's proposal is not sound, then we need real clear technical
reasons why enforcement is required, as opposed to arguments that boil
down to personal tastes.
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.
On the objective side there are a few challenges that have been well
discussed:
1. Syntactic and semantic implications of properties that return
callable entities
2. Introspection, how does one distinguish between a genuine field and a
property when necessary
3. Impact on existing and future code
On the subjective side, Walter's and my opinion and experience have been
largely aligned. With that in mind but speaking for myself unless
otherwise noted, here are some bits of my subjective opinion:
1. In C and C++ the syntax "func" or "object.method" does nothing
interesting or useful. In C, "func" is actually equivalent with "&func".
In C it's actually worse, "func" yields the type "reference to function"
which is highly restricted and obeys some rather arcane rules (in
particular it's implicitly convertible to pointer to function).
C has no methods so the syntax "object.method" does not apply to it. In
C++, "object.method" is probably the oddest construct in the entire
language: it returns a type that exists but has no name, is not
expressible syntactically, is not first class (one can't assign
"object.method" to a variable), and has only two allowed operations:
take address or apply the function call operator "()". Various C++
implementations have extensions that fix this.
Both Walter and I consider these serious lapses in language design. Two
of the most accessible elements of syntax do things of considerably low
interest and use. I hope I now clarified why I have a dim view of
arguments that - implicitly or explicitly - assume the C or C++ behavior
in this area is an example to follow on technical grounds. (Clearly,
familiarity is a much better argument.)
2. I have tried to add @property appropriately in Phobos, in particular
for ranges:
struct SomeRange {
@property bool empty();
@property ref T front();
void popFront();
}
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 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.
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.
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.
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. So
please bear with us. I understand this may be frustrating but the best
we all can do is think beyond our own preference and on behalf of the
larger community.
Thanks,
Andrei
