"Andrei Alexandrescu" <[email protected]> wrote in message news:[email protected]... > Michel Fortin wrote: >> On 2009-12-14 11:41:58 -0500, Andrei Alexandrescu >> <[email protected]> said: >> >>> Adam D. Ruppe wrote: >>>> On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote: >>>>> D2 will include properties that are understood by the compiler. We >>>>> currently don't have a design for user-defined properties. >>>> >>>> Can I suggest something very simple: make them accessible from >>>> __traits, >>>> and leave the rest to the library. Accept @anything_at_all. >>>> >>>> @myprop int a; >>>> >>>> assert(__traits(getAnnotations, a) == [ "myprop" ]); >>> >>> I just had a little related idea. If you (Eldar) put the property in the >>> naming convention, then you may be able to simplify things by using >>> __traits(allMembers, Type), which works now. >>> >>> For example: all signals start with "signal_" and all slots start with >>> "slot_". >>> >>> Would that work? >> >> It could work for simple things, but it doesn't scale well. If I wanted >> to use attributes for my D/Objective-C bridge, I'd need them to be >> parametrized: >> >> @objc("sizeWithFont:forWidth:lineBreakMode:") >> CGSize sizeWithFont(UIFont font, CGFloat width, UILineBreakMode >> lineBreakMode); >> >> Currently, this would be: >> >> CGSize sizeWithFont(UIFont font, CGFloat width, UILineBreakMode >> lineBreakMode); >> mixin ObjcBindMethod(sizeWithFont, CGSize, >> "sizeWithFont:forWidth:lineBreakMode:", UIFont, CGFloat, >> UILineBreakMode); >> >> With a naming convention, it'd have to be something like: >> >> CGSize objc_sizeWithFont_forWidth_lineBreakMode_(UIFont font, CGFloat >> width, UILineBreakMode lineBreakMode); >> >> Shorter to declare, but a pain to use. >> > > Maybe opDispatch could help the use scenario. > > Andrei
As opDispatch pushes errors from compile-time to run-time, I don't think we should be encouraging its use for anything that isn't inherently dynamic.
