D2 GUI Libs

[Michel Fortin]

On 2009-12-14 16:04:18 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

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

Yeah, perhaps opDispatch could help in the latter case, allowing you to 
call the function using the first part of the Objective-C name 
(although that's not sufficient in itself since many methods could have 
the same first part, the D short name could be "mangled" in the 
function name too).

The bigger problem is that when you use an API, you don't just call 
functions: you subclass and override functions too. It's pretty 
interesting to be able to subclass a bridged Objective-C class (such 
as, say, NSArray, NSWindow, NSApplication) and write your own subclass 
in D. Having to override functions with names like 
objc_sizeWithFont_forWidth_lineBreakMode_ is hardly interesting, and 
opDispatch can't help you with that.

Also, what is currently lacking in the D/Objective-C bridge is support 
for protocols (Objective-C's equivalent to interfaces). It'd be easy to 
support protocols as interfaces if functions in an interface could be 
annotated with the corresponding Objective-C function name.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/