Make dur a property?

[Nick Sabalausky]

On Wed, 23 Jan 2013 18:38:11 -0500
Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:

> On 1/23/13 5:40 PM, Nick Sabalausky wrote:
> > On Wed, 23 Jan 2013 15:14:21 -0500
> > Andrei Alexandrescu<SeeWebsiteForEmail at erdani.org>  wrote:
> >
> >> On 1/23/13 1:48 PM, Nick Sabalausky wrote:
> >>> Having the *caller* decide whether something is a property or not
> >>> makes as much sense as having the caller decide the function's
> >>> name, signature and semantics.
> >>
> >> No. The caller does get to decide a variety of syntactic aspects of
> >> the invocation.
> >>
> >
> > Yes, but it's unfortunate that includes a part of the syntax that
> > carries semantic/conceptual implications for something (action or
> > data) that is already *inherently* determined by writer of the
> > *callee*.
> 
> "Semantic" and "conceptual" sound interesting but are a bit out of 
> context here. We're talking simple syntax here, and in particular an 
> option available to other languages already.
> 

I realize that you think properties are purely a syntactic matter, but
that misunderstanding is the heart of the problem. You're thinking "Do
I feel like calling this function with or without parens?" That's
completely wrong and demonstrates a continued misunderstanding of
properties.

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.

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

Then you'll notice that all those edge cases created by the "optional
paren" mindset simply vanish as natural straightforward consequences of
the above rule. No need for any additional rules or "sometimes
required, sometimes optional" puzzles.

This is a problem that other languages have *already* solved, with
well-known, well-understood solutions (ie: the "action==paren,
data==no parem" rule). Unfortunately, despite the readily available
solution, D is still trying to wrap its head around the matter, and
winds up flailing around in a sea of issues because it is (you are)
desperately clinging to the failed (ie: it creates problems) and
unimportant notion of "No matter what happens with properties, I *must*
be able to decide on a whim whether I feel like calling a particular
func with or without parans". Try detaching from that desire for a while
and explore it plays out.


> >>> If anything, that's an issue with template syntax, it has nothing
> >>> to do with properties, let alone the beloved practice of abusing
> >>> properties for the sake of things that clearly are not properties.
> >>
> >> The implied assumption here is that if it doesn't have parens it's
> >> a property. Well it's a function call.
> >>
> >
> > Right, it's a function call. So what in the world do we gain by
> > allowing the caller to make it look like something it isn't?
> > Nothing.
> 
> Never answer your own rhetorical question :o).
> 

I think there's also another overrated rule that prohibits use of the
word "you" ;)

But fine:

"Right, it's a function call. So what in the world do we gain by
allowing the caller to make it look like something it isn't?"