At 05:12 PM 10/7/99 , you wrote:
> Sorry that I really can't explain well why I think that this concept
> does not fit into Haskell. I must have heard that such "typecase"
> is most often a bad design.
In most situations, type-casting is a symptom of bad design. The only C++
situation, for example, where some form of casting from a base class to a
derived class isn't symptomatic of a bad design is the situation of the
so-called "virtual constructor" -- building objects from a persistent
store, say. In most to all other situations, use of dynamic_cast or
equivalent is just plain sucky design.
I don't know enough about Haskell's type system yet to form an opinion if
there is any point where such casts are necessary as opposed to being
merely expedient. Haskell's type system is... well, I guess "quirky" and
"complex" leap to mind immediately. I'm sure that at some point I will
grok it and will either go "Aha!" or "Ew!". Until then I'll reserve opinions.
> Functions does not "belong" to the type of objects they act on, which
> is obvious when we consider functions working symmetrically on more
> than one argument: which does it belong to? And what about constants:
> in what sense does the emptySet belong to a Set type? I have never
> accepted the OO way, where the first argument is distinguished as
> the owner.
But this isn't "the" OO way. It is "an" OO way. Dylan, for example,
doesn't make any particular argument on a method as the "owner".
--
Michael T. Richter <[EMAIL PROTECTED]> http://www.igs.net/~mtr/
PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8
