Am Montag, 21. November 2005 13:37 schrieb Bulat Ziganshin:
> [...]
> > You should never use bad design to increase usability, I'd say.
>
> to be exact now i have the following definitions:
> [...]
> i prefer to replace second definition with the
>
> [...]
> data CompressedFile : FileInfo = CompressedFile {
> cfArcBlock :: ArchiveBlock [...],
> cfPos :: FileSize [...],
> cfCRC :: CRC [...]
> }
>
> and then use procedures, written to work with FileInfo, to directly
> work with CompressedFile also. now my program is full of constructs
> like:
>
> uiStartProcessing (map cfFileInfo (arcDirectory arcinfo))
> let fileinfo = cfFileInfo compressed_file
>
> and double-dereferencing about i wrote in previous letter. such change
> will allow me to omit all these superfluous code. imho, new design will
> be more natural and allow me to think about my algorithms instead of
> implementation complications
I would say, it's more natural because naturally we don't think as exactly as
we should when programming. A general file info and an info about compressed
files are two different things, although related. Allowing to silently use
an info about compressed files where a general file info is expected, hides
this difference and may, for example, result in the compiler not detecting
certain errors which it otherwise would detect.
Another problem is that your inheritance approach only solves a rather
restricted class of problems. This is, in my opinion, a general problem with
object-orientation. OO just seems to not being well thought-out to me. It
seems that the inventors of OO just had a specific class of problems to solve
in mind and then invented a system which is rather specific. On the other
hand, Haskell's type system, including several common extensions, is rather
general and therefore more flexible.
What, for example, if you have two specific kinds of file infos A and B and
also a kind of file info C which covers both A and B? You need multiple
inheritance. But if you would declare a type C which inherits from A and B,
you would also be allowed to add new fields. But this is something you don't
want since you just want to create the union of A's and B's fields.
In addition, with multiple inheritance you always have the question of whether
you should inherit a common ancestor class of the superclasses more than once
or not. If you do "inheritance by hand" by writing something along the lines
of
data CompressedFileInfo = CompressedFileInfo {
cfiFileInfo :: FileInfo,
cfiArcBlock :: ArchiveBlock,
cfiPos :: FileSize,
cfiCRC :: CRC
},
you already have all opportunities to decide how often you want to include a
certain common superclass.
I have to admit that I didn't work with OO for quite some time so my thinkings
about OO and similar things may be wrong. But I could imagine that the whole
inheritance concept is flawed, and I don't want to see flawed things in
Haskell. I always liked the fact that Haskell doesn't go the road of
object-oriented programming where, as it seems to me, you have sometimes
rather complicated rules which give you little flexibility.
Best wishes,
Wolfgang
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
