On 11/26/2010 4:21 PM, Mark Wooding wrote:
John Nagle<na...@animats.com> writes:
I'd argue that a better implementation would require that when there's
a name clash, you have to specify the class containing the name. In
other words, if A is a subclass of B, then B.foo() overrides
A.foo(). But if C is a subclass of A and B, and there's an A.foo() and
a B.foo(), calling self.foo() in C should be an error, because it's
ambiguous. You should have to specify the parent class, using "super".
How peculiar. `super' is /specifically/ for working out dynamically
which superclass to delegate behaviour to, because working it out
statically isn't possible in general.
The same issue applies in the other direction. If A and B are
subclasses of D, and A.foo() and B.foo() are defined, and D calls
self.foo(), that's an ambiguity and should be reported.
No it isn't. It's downward delegation, which is an essential feature of
object oriented design.
@This catches the case where two classed both inherit from, say
"threading.thread", each expecting to have a private thread.
Why on earth would anyone do such a bizarre thing? If you want a
private thread, then attach one as an attribute. Inheriting is simply
madness.
This must be from someone who hasn't used threads in Python.
The usual way to write a thread in Python is to subclass
"threading.thread". The subclass provides a "run" function, which
will be called from the new thread.
If you
stopped whining about how Python's object system might theoretically go
wrong if you try to use it like it was C++ and started thinking about
how to actually make effective use of the features it offers -- features
which long predate Python, and have been thought about over many years,
in languages such as Zetalisp, Common Lisp, Dylan, Scheme, and variants
of Smalltalk -- you might got on much better.
Ah, fanboys.
Of those, I've written code in Common Lisp, Scheme, and Smalltalk.
Most of the LISP variants really did objects very well; objects were
an afterthought. Smalltalk went a bit too far in the other direction;
the "everything is an object" mindset was overdoing it.
Python is reasonably well balanced in the object area.
Everything isn't an object. There are explicit classes, unlike the
instance-copying model of Self and Javascript. However,
multiple inheritance is something of a mess, as the original
starter of this thread found when he tried to document how to use it.
If you have real trouble writing documentation for a feature, it's
usually because the feature is badly designed.
John Nagle
--
http://mail.python.org/mailman/listinfo/python-list
