Properties

[Nick Sabalausky]

"Daniel Keep" <daniel.keep.lists at gmail.com> wrote in message 
news:gk9v33$1bvu$1 at digitalmars.com...
>
>
> 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
>


Same reason we have "while" and "foreach" in addition to "for".


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