Stefan Behnel wrote:
> Hi,
>
> Dag Sverre Seljebotn wrote:
>> Danilo Freitas wrote:
>>> For my GSoC work with C++ Support, I need to know if we'll use the
>>> Python '__init__' special method or use C++ way, with the constructor
>>> with the same name of the class:
>>>
>>> class Foo
>>> {
>>> public:
>>> Foo() { } //constructor
>>> }
>> Well, what is the syntax going to be for other operators? I.e. I would
>> think you could have either
>>
>> cdef extern cppclass Foo: # or whatever
>> Foo(int a, int b)
>> Foo operator+(Foo other)
>>
>> or
>>
>> cdef extern cppclass Foo:
>> def __init__(self, int a, int b)
>> def Foo __add__(self, Foo other)
>>
>> or
>>
>> cdef extern cppclass Foo:
>> cdef __init__(self, int a, int b)
>> cdef Foo __add__(self, Foo other)
>>
>> but I wouldn't feel happy about a mixture of those.
>
> +1 for XOR. Given that the semantics are not necessarily what one would
> expect from a Python __add__, and given that we need a way to support
> overloaded signatures anyway, I'm +0.5 for a syntax that differs from
> Python, such as the above "operator+". Developers who use this feature must
> be familiar with C++ syntax anyway, so keeping the declarations close to
> C++ is a plus (pun intended).
I'm not so sure. This has already been discussed, but I'll recap.
C++'s operator[] vary much from Python. There's no seperate setitem
operator, instead you use the "getitem" operator and the general C++
support for assigning to the result of a function call (i.e. in C++ you
can do a.foo(b) = c, so getitem is enough to support a[b] = c).
Also there's the host of operators which can't really be invoked from
Cython (at least easily/without magic methods to call them explicitly).
Now, there are two approaches:
A) Support the full C++ semantics. In order to get a working setitem,
you also need to support at least operator= (non-trivial, but I assume
it would actually be OK here...) and C++ references.
This leads to C++ constructor syntax.
B) Define operators in terms of "what C++ code is output". So, we have
__setitem__ on C++ classes, and simply define it as "declaring the
signature of the entire C++ stub a[b] = c".
This approach leads to __init__, IMO.
Note that B pushes the C++/Cython semantics gap to the point "before"
the cppclass decl is written, i.e. the user has to do the mapping in his
or her head. Approach A allows C++ syntax, but requires Cython to decide
how to deal with C++ semantics in each case.
I was a heavy supporter of B earlier but I'm a little bit less sure now.
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
