@property - take it behind the woodshed and shoot it?

[deadalnix]

On Friday, 25 January 2013 at 19:59:59 UTC, Andrei Alexandrescu 
wrote:
> 1. Syntactic and semantic implications of properties that 
> return callable entities
>

I don't understand why this is a special case in the first place. 
It should behave just like a variable of the same type, period.

> C has no methods so the syntax "object.method" does not apply 
> to it. In C++, "object.method" is probably the oddest construct 
> in the entire language: it returns a type that exists but has 
> no name, is not expressible syntactically, is not first class 
> (one can't assign "object.method" to a variable), and has only 
> two allowed operations: take address or apply the function call 
> operator "()". Various C++ implementations have extensions that 
> fix this.
>
> Both Walter and I consider these serious lapses in language 
> design. Two of the most accessible elements of syntax do things 
> of considerably low interest and use. I hope I now clarified 
> why I have a dim view of arguments that - implicitly or 
> explicitly - assume the C or C++ behavior in this area is an 
> example to follow on technical grounds. (Clearly, familiarity 
> is a much better argument.)
>

Javascript or C# have solved that issue with C like language 
nicely. That is why I propose to do the same here (and 
considering how much C# has been mentioned here, it sound like a 
serious option). I know that Javascript is a poorly designed 
language, but on that very specific topic most people agree that 
was has been done at the time was pure genius.

It removes the weird C/C++ object that have no expressible type, 
and simplify the situation. Additional benefice is that funName 
now behave the same in all situation, which is also a 
simplification of the situation.

> 2. I have tried to add @property appropriately in Phobos, in 
> particular for ranges:
>
> struct SomeRange {
>   @property bool empty();
>   @property ref T front();
>   void popFront();
> }
>
> There's more "@property" to be seen with "save" and "back". 
> Subjectively that just didn't work well for me. It adds clutter 
> to an otherwise simple and straightforward API, and penalizes 
> usage for benefits that I could never reap. I understand how 
> some people are glad to put that in everywhere, and find 
> meaning in requiring parens with popFront and popBack but not 
> the others. Yet for me it was liberating (see 1 above too) I 
> could just write "r.popFront" without the parens and have it do 
> its deed. It is the right semantics for a simple syntax.
>

If you ask me, I think property have been abused in range design. 
Many ranges properties really shouldn't be properties.

Additionally, this kind of boilerplate can easily be written by 
automated tools. Java or C# are very verbose, but it is very 
efficient to write program in them, as the tooling to a great job 
for you.

As I discussed with you, tooling appears slowly in D because the 
language itself is unstable, the specification have many quirks, 
and dmd is not reusable for the job.

We can either make more quirks in order to make our life easier, 
or less quirks in order for tools to make our life easier. The 
first one have immediate return on investment, however, it is 
shortsighted IMO.

> 3. Whatever we do going forward should be _simple_ but not 
> _simplistic_. Right now it's easy to forget that we're all 
> close to the subject. We have it in working memory (at least 
> it's what I think about all the time) and any incremental 
> complexity is an easy cost to absorb intellectually.
>
> But when we need to teach this to newcomers or even approach it 
> again with a "cold cache", any undue complexity will be jarring.
>

Everybody know how a variable behave. This is the most simple and 
straightforward way for a property to work.

> 4. Whether we like it or not, backward compatibility is an 
> issue. The parens or no parens aspect upon a function call is 
> too ubiquitous to write off as an obscure circumstance. So I 
> don't think the obscurity argument applies.
>
> Granted, there are several ways to approach the compatibility 
> issue, all with their specific tradeoffs. All I'm saying is 
> that careful considerations of compatibility must be integral 
> to whatever we do about this.
>

Whatever solution we choose, it will break stuff. We'd better 
think of a nice way to handle the transition than a way to not 
break code.

Think that PHP went from value typed object to reference typed 
object between 4 and 5. This is a major breakage of a codebase 
that is much bigger than D's. I was made possible by a great 
release management.

We'd better acknowledge that our release management sucks, and 
fix that, than fearing the consequences of it everywhere.