Make dur a property?

[Dmitry Olshansky]

24-Jan-2013 06:46, Nick Sabalausky пишет:
> On Wed, 23 Jan 2013 18:38:11 -0500
> Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> 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