On Wed, 23 Jan 2013 21:48:32 +0100 "Adam D. Ruppe" <destructiona...@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.)