Make dur a property?

[Nick Sabalausky]

On Wed, 23 Jan 2013 21:48:32 +0100
"Adam D. Ruppe" <destructionator at gmail.com> wrote:

> On Wednesday, 23 January 2013 at 20:37:23 UTC, Jacob Carlborg 
> wrote:
> > What about functions not marked with @property?
> >
> > writeln = "asd";
> >
> > Doesn't look very nice.
> 
> struct FileNotFound {
>     int payload;  FileNotFound opBinary(string op : 
> "+")(FileNotFound rhs) {
> return this.payload * rhs.payload;
>                  }
>                          } /* LOL INDENTATION */
> 
> FileNotFound descriptiveVariableNamesArentMyThingLOLOLOLOL;
> descriptiveVariableNamesArentMyThingLOLOLOLOL.payload = 20;
> 
> auto rofl = descriptiveVariableNamesArentMyThingLOLOLOLOL + 
> FileNotFound(100);
> 
> 
> // LOLOLOLOL rofl.payload == 2000!!!!!!!!!!!!!!!!
> 
> 
> 
> 
> All of that looks pretty terrible too, from the awful names, the 
> broken indentation, the useless comment, and of course, the + 
> operator being overloaded to mean multiplication too.
> 
> But that's no reason to for the compiler to reject operator 
> overloading, comments, or long variable names, because these 
> things are useful, when not abused by a deranged lunatic.
> 
> 
> 
> Simlarly, writeln = 10 might not look very nice, but className = 
> "foo" does.... and it is the same feature, used in real world D 
> code now (that would break if we changed it).

1. Bad comparison because operator overloading, symbol names, etc are
determined by the *callee*, not the caller. That is as it should be.

2. Strawman. The ability to write bad code is NOT valid justification
for offering a feature (ie the ability to call *any* arbitrary
single-arg function, rather than just properties, using assignment
syntax) that provides absolutely no useful value whatsoever.

Note that properties are *not* functions, they're only implemented using
functions (though D's syntax unfortunately does its best to conflate
the two notions - at least in part because those who originally
designed @property openly didn't understand and didn't like the whole
concept of properties).

Properties are fundamentally different from functions as they are used
for a fundamentally different conceptual model (yes, sometimes there is
a grey area - *SOMETIMES*, not usually). And this is a distinction that
is *inherently* made by the *callee*. The caller doesn't have a damn
thing to do with the choice other than to either get it right or get
it wrong - so why *allow* them to get it wrong? What does that gain
anyone? Not a damn thing.

Overly long variable names are NOT an accurate comparison here because
the border between good/bad variable names is impossibly fuzzy. Whereas
this, OTOH is binary: Either the author designed it as a property
or didn't. You can maybe argue with their choice in *some* cases, but
bottom line, it's either a property or it isn't. The caller doesn't
have jack shit to do with it.

What you're suggesting is comparable to allowing the caller to
determine member visibility. Or member existence, for that matter. Or
capitalization (I hate case-insensitive languages - what the hell does
that ability gain anybody other than helping to introduce inconsistency
and sloppiness? It's a non-feature - ditch it.)

(FWIW, I'm not advocating making dur a property. "minutes" is
obviously not a property of 10.)