Pyd

[Don Clugston]

Kirk McDonald wrote:
> Don Clugston wrote:
>> Kirk McDonald wrote:
>>
>>> I've just added some nifty things to Pyd:
>>>
>>> [testdll.d]
>>> extern (C)
>>> export void inittestdll() {
>>>     module_init("testdll");
>>>
>>>     def!("foo", foo);
>>>     // Python does not support function overloading. This allows
>>>     // us to wrap an overloading function under a different name.
>>>     def!("foo2", foo, 1, void function(int));
>>>     // Default argument support is now automatic.
>>>     def!("baz", baz);
>>>     // Functions and delegates can be returned into Python. (Stay
>>>     // tuned for the reverse operation of converting a Python
>>>     // callable into a function/delegate.)
>>>     def!("func_test", func_test);
>>>
>>>     wrapped_class!("Foo", Foo) f;
>>>     // opAdd is wrapped automatically
>>>     f.init!(ctor!(int), ctor!(int, int));
>>>     f.def!("foo", Foo.foo);
>>>     f.prop!("i", Foo.i);
>>>     finalize_class(f);
>>> }
>>
>>
>> I think you should swap the order of the first two arguments to most 
>> of these functions. The function being wrapped is more fundamental 
>> than the name. If you did this, you could (for example) use my 
>> newly-updated meta.nameof module to change the definition of def!() to:
>>
>> private import meta.nameof;
>>
>> template def(alias fn, char[] name = symbolnameof!(fn), uint MIN_ARGS 
>> = NumberOfArgs!(typeof(&fn)), fn_t = typeof(&fn))
>> {....}
>>
>> so that users would write
>>
>> def!(baz);
>> f.def!(Foo.foo);
>> f.prop!(Foo.i);
>>
>> Equally valid if D ever gets a built-in equivalent to symbolnameof!().
>>
>>
> 
> I agree! Most certainly. I've just been planning on doing it whenever I 
> get around to requiring (and installing :-) DDL.

Actually, it really hasn't got anything to do with DDL. Meta doesn't use 
DDL, DDL doesn't use meta. It's just that the DDL project has such great 
code, it's nice to be associated with it, and pragma wrote a 
compile-time regexp engine that's in meta. Now enki is in DDL too, and 
it also seems to be quite independent.

  The definition of
> def!() will actually be:
> 
> template def(alias fn, char[] name = symbolnameof!(fn), fn_t = 
> typeof(&fn), uint MIN_ARGS = MIN_ARGS!(fn))
> 
> (I can derive MIN_ARGS automatically now, so I now view specifying it as 
> more anomolous than specifying fn_t.)

Cool!

> I think I'll make this change in the next revision, though I'm not 
> adding the support for symbolnameof /quite/ yet.

No, it's not quite well enough tested yet.
If you just swap the template arguments, it will be something you can 
seamlessly drop in later. I really think it's just that single reference 
to symbolnameof!(), the import of nameof, and the three meta files. So 
it shouldn't be a big deal.