On Tue, Jul 28, 2009 at 11:19 AM, Andrei Alexandrescu<seewebsiteforem...@erdani.org> wrote: > Bill Baxter wrote: >> >> On Tue, Jul 28, 2009 at 10:20 AM, Steven >> Schveighoffer<schvei...@yahoo.com> wrote: >>> >>> On Tue, 28 Jul 2009 12:30:00 -0400, Andrei Alexandrescu >>> <seewebsiteforem...@erdani.org> wrote: >>> >>>> Steven Schveighoffer wrote: >> >>> What if the compiler allowed you to call functions as long as what you >>> typed was an unambiguous prefix of the function name >>> why don't we have a >>> wonderful time-saving feature like this? Because it would be a nightmare >>> to >>> read. >> >> ... >>>> >>>> So now C# has two ways of providing a readonly field. Doesn't quite look >>>> like an example to follow. >>> >>> Just like D! >>> >>> Yes, that's right. readonly is analogous to const. >> >> ... >>>> >>>> That's what I'm saying: if it could do anything, at least don't pretend >>>> it's anything special. It's a function! >>> >>> ... >>> So would you argue that C# or D with operator overloading isn't >>> better because operators are just functions, why call them something >>> else? >> >> >> Bravo! Fine, rational arguments, Steve. > > I don't think it's a good argument. Operators are functions with a specific > syntax, is all. D is not even pretending any different: it simply rewrites > the usual syntax into function calls. We should do the same with properties.
I think I basically agree with you on that except: 1) The function call syntax should be disabled on properties to avoid ambiguities like returned delegates or things with opCall. 2) the function name that properties are rewritten into should be hidden from the programmer. With opAdd etc, the function you are trying to write corresponds to a symbol, so you can't have it be your identifier. So goofy names like opAdd are necessary and unavoidable. With properties, the thing in question has a name, so it is more pleasing to actually use it. But certainly, property accesses will still be rewritten as functions. It could even be opGet_foo internally. But who wants to look at a dozen functions with names like opGet_ opSet_? Yes, my main argument against opGet_ is that it is butt-ugly. The problem is that most every class has multiple properties. So every class will have to sprout this ugliness. But sprouting a few property {...} blocks or even "property:" sections is not so bad. In fact I seen no reason why you couldn't just make the rule be that we rewrite the properties both at point of use *and* at point of declaration. property int foo() { return x_; } would be rewritten int opGet_foo() { return x_; } And I suppose I don't see any reason to stop anyone from writing the latter if they somehow find it more aesthetically pleasing. Or find it more useful for code generation or something. --bb