On Wed, 13 Oct 2010 20:57:54 -0400, Robert Jacques <sandf...@jhu.edu>
wrote:
On Wed, 13 Oct 2010 14:34:14 -0400, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
Because then we are back to writeln = 42;
-Steve
:) I see that despite not valid code for what, over a year now?, writeln
= 42 still persists.
IMO, that's because the head squeaky wheel is not really fond of
properties :) It will eventually be fixed.
That said, how exactly are we back to the verb = value "problem"?
Because you can use properties in ways they weren't meant to be used.
Specifically, you can use a getter as a setter or vice versa. I admit
it's not exactly the same problem, but it's a very similar issue.
The rearrangement ambiguity was never the expressed reason for
introducing @property. In fact, despite all the passionate posts about
how wrong "verb = value" looks, it took a very specific syntax ambiguity
with delegates/opCall to warrant language inclusion. And given the
practical problems @property has been running into, it kinda makes me
wish I had run across the uniform access principle
(http://www.eiffel.com/general/column/2005/Sept_October.html) back
during the debates.
I must have said this a hundred thousand times. It has to do with the
power of the author to define usage. When you let the user define usage,
confusion ensues. To me, the delegate issue is a nice bonus, and if
that's what pushed property acceptance over the edge, so be it.
Without the restrictions, the author loses the power to define usage, and
he resorts to creating more verbose language like getFoo instead of just
foo. Welcome to Java.
-Steve
