Properties

[Daniel Keep]

Jérôme M. Berger wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Daniel Keep wrote:
>>
>> Michiel Helvensteijn wrote:
>>> [Condensed: syntax sucks, let's introduce more!]
>> I might be old fashioned (get offa mah lawn!), but I've always found
>> something like the following quite acceptable:
>>
>> class Foo
>> {
>>     mixin(properties
>>     ("
>>         rw int bar;
>>         ro float baz;
>>         wo Foo zyzzy;
>>     "));
>> }
>>
> 	Note that this is a very limited use for properties. Defining
> properties isn't just a question of access control (read/write, read
> only, or write only).

For me, it *was* a case of access-control... at least, it was about 80% 
of the time.

I'm a fan of interface-heavy design: make an interface for every 
distinct kind of functionality and pack them all together.  That means I 
end up with a metric buttload (equivalent to about 42 imperial piles) of 
properties.

And most of them were just accessors that needed to be in the interface; 
hence the functionality of the mixin.

 > It is also a way to execute arbitrary code
> each time the value is changed (or accessed), ...

It's been a while since I used the code, and honestly I can't seem to 
track it down, but I recall that I could do this:

   mixin(properties(" rw int bar; "));

   protected void bar_onSet(int newValue) { ... }

There was also an *_onGet, and you could block setting a property by 
throwing an exception, I believe.

Granted, this doesn't cover every possible use-case, but then it's not 
supposed to; it's supposed to make the 90% easier.  It still did the 
assignment, since I felt you shouldn't be making properties that have a 
setter that doesn't set anything...

 > ... or to create
> properties that don't correspond to actual data fields (complex
> module and argument come to mind).

If the property doesn't correspond to a physical field, then you're 
going to have to write the code to handle it from scratch.  And no 
matter WHAT you do, it's eventually going to boil down to one or more 
functions.  Which is EXACTLY how they currently work.

What would be the point of making a special syntax when you can already 
do that? :P

 > How would you do that with
> mixins? (Not that it would be impossible, but the syntax would
> probably be horrible).
> 
> 		Jerome

On a somewhat related note, I've often pondered writing a very limited D 
parser in CTFE to do this sort of thing more easily, but never got 
around to it, nevermind the CTFE memory bugs...

   -- Daniel