At 04:49 PM 4/23/2007 -0700, Guido van Rossum wrote: >>I suppose there is some value in requiring people to override @abstract >>methods to make a subclass instantiable, versus merely using the lack of an >>@abstract class decorator to indicate that a subclass is concrete. But I >>wonder if being able to have just one @abstract decorator (that always >>means "you can't call this by default") mightn't be worth giving up that >>tiny bit of extra type checking? > >I prefer to follow the lead of C++ here -- an abstract class is >abstract by virtue of having at least one abstract method.
It's been way too long since I did any C++, but isn't it the case that an abstract (aka "pure virtual"?) method in C++ is one that *can't be invoked*? [pause to Google it...] Well I'll be darned. I didn't know you could actually provide an implementation for a pure virtual function. Hm. Learn something new every day... except while I was writing C++ evidently. :) But are there any other languages besides C++ that have this idiom? I'm not familiar with any that do (at least, not that I know of!), and the fact that C++ allows it seems a bit non-obvious to me. Java and C# pretty much do @abstract the way I proposed it, for example: Java: http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html C#: http://www.codeproject.com/useritems/Abstract_CLS_MTHD.asp That is, they both separate class-abstraction from method-abstraction, even though the latter implies the former. Thus, you can have an abstract class 'Iterator' even if all its methods are non-abstract. (However, if any of its methods are abstract, the class itself is required to be abstract.) As someone with more recent background in Java than C++, I find the idea of abstract methods having an executable implementation to be quite confusing, and suspect that other people with that Java or C# background will do the same thing. That is, skim the explanation and miss the significant difference between the C++ way and what they're used to. >That the abstract methods are still somewhat useful implementations is >mostly to provide a valid (if not necessarily useful) end point for >super-calling in cooperative MI schemes. Right; I guess my point is that if those "somewhat" useful implementations are useful, they're useful, and there's no need to treat the corresponding class as "abstract" (in the "non-instantiable" sense) in that case. For example, I could pass an Iterable() to something that expected an iterable. _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
