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
