Reddit: why aren't people using D?
Daniel Keep
daniel.keep.lists at gmail.com
Sat Jul 25 02:28:49 PDT 2009
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;
}
})
);
}
More information about the Digitalmars-d
mailing list