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 ;)
