@property

[Steven Schveighoffer]

On Thu, 24 Jun 2010 17:11:08 -0400, Pelle <pelle.mansson at gmail.com> wrote:

> On 06/24/2010 10:45 PM, Steven Schveighoffer wrote:
>>
>> How is this confusing? It's a read-only property. They are used in
>> countless design patterns.
>>
>
> The confusion isn't their existence, but rather deciding what is a  
> property and what is not.

That is an addendum to deciding the name of the function.  Property-or-not  
is a name decision, and is as arbitrary as deciding a good name for a  
function.

>> Furthermore, how will allowing any no-arg function to be called without
>> parentheses *not* lead to confusion?
>
> Note that many languages never require parentheses, and they're not  
> particularly confused.

D is of C lineage, and as such, should follow C's conventions -- parens  
for functions, no parens for properties.

>
>>
>> struct File
>> {
>> bool open() {...}
>> }
>>
>> File f;
>>
>> if(f.open) // looks to me like a property saying whether f is open
>> if(f.open()) // looks to me like a function opening f.
>>
>> Like it or not, the parentheses are part of the name of the
>> function/property, and to not be able to control whether parens are used
>> as an author of said function/property leaves me to answer unending
>> requests for changes to the API, such as "why don't you change open to
>> openFile to make it clear that it's a function." Hey, look, we're back
>> to Java's getX and setX, but in reverse! Wheeee!
>>
>> With @property, I don't have to do that, because it's very obvious that
>> since open requires parentheses, it is effecting an action on f.
>
> I feel this is a naming issue, not a @property-issue. Is the empty() of  
> a range a property? Is the save() a property? It's just up to anyone to  
> guess and argue either way.

This is why you are confused -- @property *is* a naming issue.  The  
difference between the hackish D current syntax and the sane @property  
syntax is that in hackish D, the caller gets to decide how to name the  
function, which doesn't make any sense.

And the problem is precisely that it's anyone's guess.  It should be up to  
the author of the structure.  It should *not* be up to the user of the  
struct to 'guess'.

How about we get rid of case-sensitivity, so people who like to use all  
caps can have their say in how they call your functions.  Does it make any  
sense?  How about we allow spanish translations of english terms to be  
used?  How about just unambiguous prefixes?  Any naming issue should be  
decided by the author of the function so that 1) it's consistent  
everywhere it's used and 2) the author is free to imply a meaning without  
resorting to overly verbose text.  To allow otherwise causes way more  
confusion than some author who can't decide on whether something is a  
property or not.  I very seldom run into cases where the name of the  
function is obvious, but whether to make it a property or not isn't.  I  
always consider the property/no-property question when deciding the name.   
Empty is a perfect example -- property through and through.

Save is not as obvious, but that's because the author decided the name  
without considering whether it should be a property.  If it should be  
considered a property, it should be a noun (not a hard rule, but it makes  
more sense that way).  I'd say something like 'copy' would look better as  
a property.  But IMO, save provides almost no utility so that leads to it  
being hard to name.  Blaming property syntax is not the way out.

>
>> @property is much better than the current situation, even for getters.
>> C#, python, I'm sure other languages, have worked fine for years with
>> explicit properties, this debate is non-existent there.
>
> And paren-less function calls have worked fine for years in a bunch of  
> other languages. This debate is non-existent there as well.

Do those languages allow parentheses?  Do they allow calling functions  
with parameters without parentheses?  If the convention is parentheses are  
forbidden or always optional, it's less confusion, because you can't  
assume anything from the parentheses or lack thereof.  I don't see how we  
are better off not being able to use parentheses to disambiguate semantic  
meaning.

-Steve