"Daniel Keep" <daniel.keep.li...@gmail.com> wrote in message news:gk9v33$1bv...@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
