Jarrett Billingsley wrote:
On Mon, Jul 27, 2009 at 11:13 PM, Andrei
Alexandrescu<seewebsiteforem...@erdani.org> wrote:
Rainer Deyke wrote:
Benji Smith wrote:
3) The existence of "magical" identifiers complicates the language
design. Because the rules that apply to those magical identifiers is
different than the rules applying to non-magical identifiers.
I don't see how that's the case. Everywhere opGet_foo appears, it is
treated exactly like every other identifier.
The only thing "special" about these identifiers is that they can be
generated automatically by the compiler. When the compiler sees 'a.b',
and 'b' is not a field or method of 'a', it rewrites this to
'a.opGet_b()'.
Oh. You stole my thunder.
+1
While the opGet_foo and opSet_foo are okay, what are your thoughts on
the 'property' attribute on a function?
My opinion? I'd like to render it unnecessary.
I know you said you didn't
really like the idea of having to name your range's empty function
'opGet_empty'.
Correct. I'd rather try to disambiguate the rather rare case when a
property returns a delegate etc. For me, I get a breath of fresh air
whenever I get to not write "()". I can't figure how some are missing it.
The property attribute also has the nice property
(heh) that you can call the property setters and getters either as
properties or as functions (i.e. "r.empty" or "r.empty()").
Basically, the behavior would be *exactly* as it is now, except you'd
have to explicitly state with which functions it would be legal.
I guess I'd rather not have to specify that. I'd do that on all of my
functions that don't take parameters. To me that's syntactic noise and
an unnecessary special case.
Or is the idea of introducing the 'property' keyword too controversial?
In this case the keyword isn't even the largest aggravation. The largest
aggravation is that everybody is with their hand on the syntactic
holster when they should look into simplifying and unifying, not adding
more baroque adornments for what is really some function calls.
Andrei
