On 2009-12-14 16:04:18 -0500, Andrei Alexandrescu
<[email protected]> said:
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.
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
[email protected]
http://michelf.com/
