Dag Sverre Seljebotn wrote:
> Robert Bradshaw wrote:
>> I think we're going to want to support the operator= in a limited
>> sense that one is allowed to do conversions from one type to another
>> (the declaration could be totally different, and potentially the same/
>> similar as whatever we settle on for "operator T()"). So rather than
>> the hypothetical
>
> a) I don't see where operator= enters the picture here.
> b) Even if you could do this, this is only hot-fixing one very specific
> consequence of a much larger body of problems. I have a feeling you
> could go around forever fixing specific cases with native Cython support
> and get something massively complicated (and impossible to guess)
> compared to my proposal for embedded C++ macros.
This was rather unfair of me. You said:
"""
I would prefer
class MyCollection:
X __getitem__(K idx)
"""
Which is not by any means a hotfix, as it is just mapping over the C++
declaration!
So I'll rephrase: Until I see it, I remain curious about how one is
going to select a subset of C++ semantics to support which
a) maps to Cython semantics without too many wierd, exceptional rules
which one has no chance of guessing (which then defeats the purpose of
pretending to support operatorX-notation in the first place)
b) allows wrapping of most C++ libraries without writing a wrapper
C++-side which is more Cython-subset-friendly.
(Problem with wrapper C++ side: I think one would have to subclass
classes C++-side, which would leave descendants in other libraries in
the cold. Though multiple inheritance *could* save us here.)
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
