Jarrett Billingsley escribió:
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? I know you said you didn't
really like the idea of having to name your range's empty function
'opGet_empty'. 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.
Or is the idea of introducing the 'property' keyword too controversial?
I mean, if it is, there are plenty of keywords in D that *only* have
one meaning. I'm sure one of them could be repurposed ;)
Another problem with the opGet_foo approach (which I find quite ugly to
my eyes) is that it's less backward compatible. As Andrei said, he'll
have to rename empty() to opGet_empty(). The compiler will also be a
little slower because for each function it'll have to make a match to
see if it starts with opGet or opSet. There's also the thing to worry
about not letting "int foo" and "int opGet_foo" to coexist.
And currently D has 106 keywords. I think no one will care if it has
107. :-P
