D2 GUI Libs

Nick Sabalausky a at a.a
Mon Dec 14 17:56:12 PST 2009


"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:hg698i$2rpd$1 at digitalmars.com...
> Michel Fortin wrote:
>> On 2009-12-14 11:41:58 -0500, Andrei Alexandrescu 
>> <SeeWebsiteForEmail at erdani.org> 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.





More information about the Digitalmars-d mailing list