2009/4/26 Dag Sverre Seljebotn <[email protected]>: > Greg Ewing wrote: >> Dag Sverre Seljebotn wrote: >> >>> (Note that C++ overloading on return type in the specific case of the >>> conversion operator, "operator SomeType". I.e. you can have "int a = x; >>> float b = x" invoke two different methods on an x object to do the >>> conversion.) >> >> But that's not overloading on return type -- it's not >> even overloading at all, since they're different >> methods. >> >> Overloading on return type would be if >> >> int a = x.foo() >> >> and >> >> float b = x.foo() >> >> were to select different versions of the foo() method >> based on their return types. I don't think C++ does >> that (although I might be wrong). > > I suppose you are right. Although the *effect* can be simulated by > having foo() simply return an object with conversion operators which > call two different methods: > > class Result { > public: > operator float() { return 2; } > operator int() { return 3; } > } > Result foo() { return Result(); } > > int a = foo() // a == 3 > float b = foo() // b == 4 > foo() // nothing can happen, no side-effects possible > > So the reason I end up with overloading on result type in Cython is > because then you can declare the interface while ignoring the Result > class and have things work the right way. > > But it was just a throw-away idea, like I said to Robert, I'm much more > worried about > > foo() = 3;
If no type defined, maybe an overloaded function with PyObject work. Or using type() function. So, the parser would know the overloaded method we want him to use. _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
