new DIP5: Properties 2

[Steven Schveighoffer]

On Fri, 31 Jul 2009 22:37:06 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Steven Schveighoffer wrote:
>> On Fri, 31 Jul 2009 16:53:12 -0400, Andrei Alexandrescu  
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> Steven Schveighoffer wrote:
>>>> But in the case of properties only allowed without parens, functions  
>>>> require parens, you are defining a rule for the compiler.  Think of  
>>>> the parentheses as an extension of the function name, like  
>>>> punctuation.
>>>
>>> But you say no parens means query, parens means action. This is sheer  
>>> unchecked convention.
>>  But we already have sheer unchecked convention!  I could make a  
>> function called sort that reverses an array.
>
> Of course we do. My point is that there's no need to add gratuitous  
> mechanisms fostering conventions that go unchecked.

We already had those conventions.  D took them away by allowing any  
function to be treated as a property.  You could argue the same points for  
the current D property system -- specifying x = y translating to x = y()  
doesn't add any extra checking or benefit at all except for you like the  
way it looks better.  I still am amazed that you see no benefit to  
punctuation differences in names.

>
>> I don't get why it makes any difference to you that the meaning of  
>> parentheses and no parentheses is used by the author of the function.   
>> How is this bad or somehow worse than what we have now?  If you don't  
>> trust the author's functions do what they are named for, don't use his  
>> functions and properties.
>
> Well you can trivialize all you want but the matters are different. It's  
> one thing to have good names, good designs, trusted code etc. and a  
> whole different thing to define a feature of which entire existence only  
> serves only an unchecked convention.

It serves a purpose -- one that is not functionally checkable or  
definable, but is interface to a human being.

Look, if D decided to make function calls case insensitive because "some  
people like to call with their own case", nobody would go for it.  But  
let's say it did happen, and people requested that we make things case  
sensitive again.  The argument that it doesn't serve any checked  
convention is ludicrous!  I don't want a checked convention, I just want  
to name my classes with capital letters for my conventions dammit!  The  
ability to name things how we want and expect them to be called by the  
name we give them is fundamental in human interface definition!  Not being  
able to specify the calling convention makes you A) come up with ugly  
verbose names like isEmpty, getProperty, C_classname, or B) deal with the  
ensuing bug reports "how come you named it empty instead of isEmpty  
because if you call it like empty(), it looks like you are emptying  
something".

How about I just start calling you Andray because it's the same to me as  
Andrei.

>
>> Since C was invented, we have had the convention that () means  
>> function, lack of () means property.  You are acting like the last 37  
>> years of programming languages never existed, and this is some "new  
>> radical" convention.  D is of C lineage, so using long standing C  
>> conventions should not confuse people.
>
> Well C never had properties that executed code, so following the lineage  
> is a moot point. C also didn't have a variety of other things, such as  
> member functions. But we do have now. All I want is to not add undue  
> burden. To me, it would be a mistake if D defined a special syntax for  
> defining properties as if they were some big deal, to then not check in  
> any way that they behave any different than regular functions.

The check is in the implication the human sees.  x.empty() => empty x;  
x.empty => is x empty.  No functional check is necessary just like no  
check is necessary to ensure that empty doesn't print "asshole" to the  
screen.  The implication is in the meaning of the word coupled with  
punctuation long perceived *by the user* as defining an action.  C had  
properties, but they were limited to only returning a value and setting a  
value.

Why do you think Java defines properties as getX and setX instead of just  
x?  Because they don't have a way to get rid of the parentheses.  So they  
want to make it clear because parantheses imply action that the action is  
getting or setting x, not x'ing.

>>> Maybe less confusion, definitely more burden.
>>  The burden is on the author to come up with meaningful function names  
>> already.  With real properties, at least that task is easier because  
>> you don't need to add extra context to ensure a word is treated as a  
>> verb or a noun (e.g. 'isEmpty' in order to make sure someone doesn't  
>> mistake 'empty' for an action).  The compiler enforces the requirement  
>> of property syntax vs. function syntax, so no burden there.
>
> No, you add burden by posing the question, do I want people to call with  
> parens or without? There's always going to be a gray area and there's  
> always going to be surprising APIs (see e.g. Daniel Keep's point about  
> range APIs that must actually do stuff in r.empty). With a uniform  
> convention, all of these issues vanish.

I grant you that people will certainly stray from the norm, gray areas are  
unavoidable.  Sometimes you have to bend the rules a little bit to achieve  
what you want, this is no exception.  But for 99.99% of the time, the  
convention can be used.  That one or two times you have to implement  
something weird that doesn't follow the convention doesn't make the whole  
convention invalid! You note the exception and move on.  For example, look  
at Rebindable!(T) where you clearly violate the rules of const, does that  
make all of const invalid?  Oops, I can't implement Rebindable without  
breaking the rules, this const shit can't be guaranteed, so I reject the  
idea of const altogether.

Daniel's point about range APIs doing stuff in r.empty has nothing to do  
with it, since the meaning is "is this range empty."  Some would like that  
to mean "you're just giving me a simple value so you shouldn't have to  
mutate the object,"  but to me it *reads* "is this thing empty, do  
whatever it takes to answer that question, including mutating the object  
if you have to."  Guess what, you still have to deal with that problem,  
even without property syntax.

> To clarify: if there was any extra checking by the compiler, any  
> guarantee that the feature would provide at all, I'd be glad to pay the  
> price of thinking more when putting together a design. But you want to  
> define a language feature that allows people to require "()" or not as  
> they please, and that's all. It's a frivolous detail to be spending time  
> on when designing an API. I simply don't believe that's good language  
> design.

Yeah, those moronic language designers who make C#, Java, Python, etc.  
don't know what they're talking about.

I give up.  I don't see any way to break through to you.  Hopefully  
someday someone whose opinion you *do* value criticizes D for having  
ambiguous calling conventions, and then you are forced to change it.

Until then, I have better things to do.

-Steve