class "type" and metaclasses (was Re: Style for overwritten methods of abstract classes)

[Alex Martelli]

"Stefan Schwarzer" <s.schwarzer at ndh.net> wrote in message
news:3C38D830.43278623 at ndh.net...
    ...
> I don't know if this question is related but it appeared to me some
> weeks ago: I can define __int__ etc. in my classes to provide an
> "opportunity" for int() to "convert" an instance of my class into an
> int. I have not seen something like this for e. g. __list__, so I could

Define __iter__ instead: that's what list(x) calls, as well as any
"for item in x" loops.  It makes no difference for list(), but, for
loops, it may be a crucial saving of resources to be able to generate
the items one by one, each only as needed, rather than having to
build the whole list in memory at the same time.


> On the other hand, I don't know if I would really like it. C++ does so
> many things automatically that it's not so easy to keep all these rules
> in mind and consider them when it's necessary. I like the simplicity of
> Python. :-)

I agree that C++'s utter complexity is C++'s key defect, and that much of
the complexity comes from the desire to offer "convenient" automatic/default
behavior in so many different and slightly overlapping cases.  And I share
your appreciation for the simplicity achieved with Python.

But I don't see how these consideration apply to Haskell-ish typeclasses
(which are not offered in C++, anyway).  Isn't their superiority over C++'s
"abstract classes" rather obvious?  And what diminution of simplicity do
you see in Haskell typeclasses when compared to C++ abstract classes?

In a C++ abstract class you basically *have* to over-constrain -- decide
at abstract-class-design time which methods are "more fundamental" than
others, when in fact there may be no such constraint in the abstract
system you're modeling.  Where's the simplicity gain in this?


Alex