Andrei Alexandrescu wrote: > Rainer Deyke wrote: >> Ary Borenszweig wrote: >>> Maybe what scares Walter is a whole new syntax for properties. If at >>> least you could say which functions are properties and which are not, >>> that would be a small change and it'll make it possible for other >>> things. Something like: >>> >>> int property foo(); // getter >>> int property foo(int value); // setter >> >> My proposal requires no new keywords and no new syntax: >> >> int getfoo(); // getter >> int setfoo(int); // setter > > This is pretty clean, and in keep with the opXxx approach. Actually how > about defining property foo by defining opGet_foo and opSet_foo. > > Andrei
Actually, if this became the "official" way of doing properties, that would solve the IDE and debugger issues and (hopefully) the parens thing. Which leaves only one issue: that writing properties violates DRY. So I wrote a basic Property generator. Full source is here: http://gist.github.com/154755 I know people hate mixins, but this approach would give us discoverability and a slightly terser syntax, without having to actually introduce new language syntax. And maybe if D ends up with enough of these mixins being used as standard, it'll spur Walter into adding macros. :D Examples from the code: struct S { mixin ( // Default accessor property with automatic private storage. Property!(int, "bar") // Public read-only w/ auto storage ~Property!(int, "baz", null, "private") // Public read-only with default ~Property!(int, "bop = 42", null, "private") // Read-only ~Property!(int, "qux", null, "-") // Fully custom; no auto storage created ~Property!(int, "zyz", q{ return 7; }, q{ // Note "magic" value argument writefln("Set zyz to: %s", value); }) // Fully custom with private setter and auto storage ~Property!(int, "gfh", q{ // Public here is optional public { return storage/100; } }, q{ private { storage = value*100; } }) ); }
