24-Jan-2013 06:46, Nick Sabalausky пишет:
On Wed, 23 Jan 2013 18:38:11 -0500
Andrei Alexandrescu <[email protected]> wrote:
The real question is "Is this an action or data?" (And obviously I mean
when viewed from outside the encapsulation, I don't mean the
implementation.) Note that the answer to that question is NOT
subjective to the context of the caller, only the callee. Blindly
discounting the "conceptual" matter (ie "action or data?") is a
convenient way contort the issue so that it fits back into the "Call
with/without parens?" strawman.
These days properties imply an action of, well, obtaining said value. If
it's a wrapper as in "return zis variable" something is wrong already.
There have already been enough problems shown that have arisen as a
direct result of mistreating the matter of properties as merely
an "optional paren" syntax matter. You suggest various additional rules
to patch over those symptoms, but when you consider the very simple,
time-honored, and frankly very very common, association of:
foo.bar() // Perform action
foo.bar // Read/Write data
The same argument was brought about overloading operators, about
overloading functions, etc. In other words the argument is WYSIWYG, but
humans inherently think in overloaded notions and take obvious shortcuts
just about everywhere.
Also what about x.y itself? Unlike in C/C++ you don't know if x is a
pointer or not. And so what? Add to this possible static members, D
already cuts corners and not at all WYSIWYG. Also see the opDispatch
problems as it can be either property or not. @property on its own
brings a lot of schism.
What makes all of the engineering, science etc. domains usable at all -
is an optimized/overloaded/shortened vocabulary. In this light extra
parens are redundant and thus skipped, end of story. Feel free to impose
a coding standard that requires usage of these and see how it goes.
--
Dmitry Olshansky
