On Sat, Aug 13, 2011 at 4:09 AM, Dag Sverre Seljebotn <[email protected]> wrote: > I read up on Go's interface model last week and am very excited about it. > Perhaps this was old news to a lot of you, but it was new to me. > > This post is mostly just to make sure everybody is aware of prior art here > in case it is a good fit for Cython down the road. I hope I'm not starting a > long wasteful thread, let's keep it FYI, and if it's interesting I can try > to learn a bit more of the technical details and write up a CEP prior to > next summer's GSoC or something... > > The idea of polymorphism in Go might be phrased in the Cython language as: > > cdef interface Walker: > int walk(float) > > cdef class Foo: # note: Does not inherit from Walker! > cdef int walk(self, float length): > .... > > > def f(Walker obj): > obj.walk(2.3) > > f(Foo()) > > This is duck typing, in the sense that Foo has no knowledge of the Walker > interface (at module compilation time) -- it just satisfies it by > implementing the same interface. The point of casting/conversion has all the > information needed to build the vtable (somehow...). This of course uses a > little more memory, but it is still bounded by the number of code lines you > could write... > > This has a lot more flexibility (libraries don't have to agree on which one > should have the "ultimate superclass", they can just agree on method names), > and it just fits my brain and workflow much better as well: I'd use > profiling to pinpoint the spots where I really need a vtable instead of dict > lookups, and then it is more natural to introduce the interface in the > caller, rather than to go back into the callee to introduce a type hierarchy > (which might be more geared towards optimizing calls than towards what type > relation is "natural").
These are exactly the kinds of thoughts I had when I first saw Go interfaces, including wanting to add this idea to Cython :). In order to take advantage of static typing, could there/should there be an error/warning for trying to invoke a method not offered by the interface? (Or would the "yellowness" in cython -a be sufficient for the careful user.) > Implementing this in Cython is likely going to be tougher than in Go if we > want to support <Walker>obj, where obj has type "object", and not only > <Walker><Foo>obj. But I'd think it is not impossible, just somewhat more > costly on assignment...but that is often amortized over multiple calls. I was thinking about caching this data to the class object (say, in its dict) and grabbing/creating it on assignment/casting. A custom implementation as described above could perhaps be faster. - Robert _______________________________________________ cython-devel mailing list [email protected] http://mail.python.org/mailman/listinfo/cython-devel
