On 2009-08-02 23:19:50 -0400, "Robert Jacques" <sandf...@jhu.edu> said:
On Sun, 02 Aug 2009 20:53:35 -0400, Michel Fortin
<michel.for...@michelf.com> wrote:
On 2009-08-02 20:18:51 -0400, "Robert Jacques" <sandf...@jhu.edu> said:
I also like the idea of omitting parenthesis for functions with no argument.
I like it too. But the problem with the current approach D are:
1. A syntax that permits function to be called both without and with
empty parenthesis creates ambiguities when it returns a callable type
(a delegate or an object with an opCall member).
2. We want properties to be nouns, and actions to be verbs. In english
a lot of words are both nouns and verbs, which makes it impractical to
distinguish a property from a function by its name alone.
Solving 1 involves having a way to say functions that can and must be
called without parenthesis. Unless we want to force all functions with
no parameter to be called without "()", we must have some kind of flag
to tell us that a function expects or does not expect "()".
Solving 2 involves making a difference in the call syntax between
property and action functions. Since the idea behind a property is to
mimic a field, it follows that the best differentiator for properties
is the lack of parenthesis.
I'd be glad too if we could continue to skip parenthesis for calls to
functions with no arguments, but I think fixing the two problems above
is more important.
I agree 1) is an issue, but I view it as a corner case. (I use zero/one
arg functions all the time and make use of the 'property' syntax left
right and center, but I've never run into the opCall problem) It would
be nice if it were fixed, but we may be cutting off the nose to spite
the face, as it were. (Or alternatively, taking the scientific instead
of engineering approach)
Problem 2) I think is a major logical flaw: a property is a function.
So I see no need to distinguish between the two. Properties, in fact,
can be a very expensive functions that takes locks/do database
lock-up/etc. So making syntax changes that make 'properties' look
cheap and 'functions' look expensive is worse than what we have today.
Today, at least, everyone knows that no parenthesis doesn't mean
necessarily cheap O(1) operation.
And I agree with you: properties are functions. But problem number 2
isn't about whether properties are functions or not. It's about the
meaning of a name. Say you have a "transform" function, you'll have
some expectations about what it does based on the name. So I ask you:
is a "transform" function an *action* (a verb) in the sense that it
applies some transformation to an object, or is it a *property* (a noun
or adjective) in the sense that it returns something like an affine
transform associated with an object? The semantics of the two are
completely different, yet they share the same name.
The real ambiguity here is the English language, were many nouns and
adjectives are also verbs. We could switch to a natural language that
does not have this problem for function name -- say French: "transform"
becomes "transformer" (action, verb) or "transformation" (property,
noun); "empty" becomes "vider" (action, verb) or "vide" (property,
adjective) -- but that doesn't seem like a very practical option.
So, beside switching to a non-English language, we have two other
options. First we could write a guideline saying properties (nouns and
adjectives) should start with some prefix. I tried it[1]. I couldn't
come with anything sane that works for non-boolean properties. In
addition, most people don't read guidelines, and educating people to
write "is", "has" or a modal verb in front of boolean properties would
be a major effort. It works in Objective-C, but Objective-C function
naming conventions are very different.
[1]: http://prowiki.org/wiki4d/wiki.cgi?DProgrammingGuidelines
So the only option left, assuming we still want to solve the problem,
is to introduce a formal syntax in D to distinguish properties (nouns
and adjectives) from actions (verbs). A natural fit for that at the
call site is to use the syntax without tailing empty parenthesis for
properties, mimicking fields, and use the inherited function syntax
from C-derived languages for actions. Choosing the right syntax for
property definitions is a greater challenge since we want a simple
syntax that helps people make the right choice depending on wether they
want a property or an action, but we (Andrei, me, some others) don't
want to deviate too much from a regular function either.
As for whether properties should be cheap (not perform anything
heavyweight) or not, that's another debate result in a guideline.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
