I'd like to make a different suggestion. What about a keyword to pass after cdef in the declaration of the object to indicate the vtab can be skipped? I e an assertion that the object will be of the declared type. This will maintain better compatibility with Python.
cdef Foo bar = Foo() cdef inline Foo fastbar = bar bar.method() # through vtab fastbar.method() # direct call SM Den 11. jan. 2010 kl. 19.55 skrev Robert Bradshaw <[email protected] >: > On Jan 11, 2010, at 1:00 AM, Stefan Behnel wrote: > >> Robert Bradshaw, 07.01.2010 22:06: >>> On Jan 7, 2010, at 12:34 PM, Neil Ludban wrote: >>>> Classes defined in extensions must explicitly indicate that they >>>> support subclassing from pure Python. NoneType and bool are core >>>> types that don't, there may be others. >>> >>> Ah, I did not know that. That does make a final modifier more >>> attractive. This is a larger change to the language than allowing >>> inline methods (with an error if one attempts to override them). >> >> I'm +0 on 'final' classes. I don't see a major use case, although >> there may >> be. Some extension types are really just meant as containers for C >> types, >> and when they are created from module internal code only, there may >> not be >> much value in subtyping them (although lxml.etree makes a good >> counter >> example). >> >> Anyway, if it's supported by CPython, it should be ok to support it >> in >> Cython, I guess, as long as users are aware that this really means >> that >> they put a serious restriction on the usage of their code, and that >> this >> should be used with caution. >> >> I certainly have seen enough Java code where 'final' was getting in >> the way >> at some point (and wasn't easy to remove from externally maintained >> code), >> or where the keyword was used totally arbitrarily in places where the >> compiler can easily infer the semantics anyway, and where it just >> adds >> noise to the code. I always expect an important intention when I see >> this >> keyword in code, and when there isn't one, it tends to confuse me, >> because >> it doesn't give me the feeling that I have understood the code. >> >> >>>> The intended point was that the semantics of making a class "final" >>>> are understood and would imply the requested optimizations, while >>>> the "inline" keyword wouldn't fit at all in this context. >> >> IMHO, "inline" fits exactly the intended optimisation, whereas >> "final" >> doesn't imply (and certainly not request) any optimisations at all. > > It just makes it safely possible. I am also of the mind that declaring > something final so that it can be optimized is less obvious and > straightforward than just declaring it inline in the first place. > >>> The inline keyword is nice because we already use it for functions >>> (where the final keyword makes no sense). I think it's probably >>> worth >>> introducing both keywords, where inline would control emission of >>> the >>> C inline directive. (Of course for non-inline final methods, the C >>> compiler could decide whether or not to actually inline.) A class >>> could be final, with the same semantics as java. One question is >>> would >>> inline imply final, or require it? >> >> It makes no sense without final, > > Well, given that it's technically only a hint that the compiler C can > ignore, and nearly always would for virtual methods, it would make > sense but not be very useful. > >> so it should imply it (and certainly not > > That's what I was leaning towards as well. > > So, it sounds like +1 to inline methods (with the implication that > they have final semantics), and lets hold off on adding the final > keyword to the language until a CEP with compelling justification as > it is a more significant change to the language. > > - Robert > > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
