[Haskell-cafe] records proposals list

[Wolfgang Jeltsch]

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