On Mon, Nov 21, 2005 at 02:48:48PM +0100, Wolfgang Jeltsch wrote:
Am Montag, 21. November 2005 14:27 schrieb David Roundy:
On Sun, Nov 20, 2005 at 04:21:05PM +0100, Wolfgang Jeltsch wrote:
Am Samstag, 19. November 2005 17:35 schrieb Bulat Ziganshin:
7. OOP-like fields inheritance:
data Coord = { x,y :: Double } data Point : Coord = { c :: Color }
of course this is just another sort of syntax sugar once we start using classes to define getter/setter functions
I thought that even many OO people say that inheritance of fields is not good practice. So why should we want to support it?
Think of it instead as being syntactic sugar for a class declaration:
class Coord a where get_x :: a -> Double get_y :: a -> Double set_x :: Double -> a -> a set_y :: Double -> a -> a
As I pointed out in another e-mail just sent, this kind of special syntax only solves a very specific problem so that it's questionable whether this syntax should be included into Haskell. However, if we manage to create a more generalized approach, inclusion of it into the language might be quite fine.
In addition, having a line which begins with "data" declaring a class is *very* misleading, in my opinion.
Data lines declare instances all the time via deriving. If something like this were implemented--and really this applies to any scheme that creates functions to access record fields--there would need to be a set of implicit classes for field access. To fix the namespace issue with field names, the only two solutions (as far as I can tell) are (a) Don't create getter or setter functions for field access. This is what the SM proposal does. (b) Create some sort of class that allows getter and/or setter functions for field access. (a) involves the creation of a non-function syntax for something that is essentially a function--and means you'll need boiler-plate code if you want to create accessor functions. (b) means a proliferation of classes, which is perhaps more problematic, but you gain more from it--you avoid the requirement of a special syntax for accessing fields of a record. So if some variant of (b) is practical, I'd vote for it. I'm not attached to the inheritance idea, but it's basically a limited form of (b). -- David Roundy http://www.darcs.net