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