On Thu, 24 Jun 2010 17:11:08 -0400, Pelle <pelle.mans...@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
