Re: [Haskell-cafe] Subclass or no subclass?

Here's another thought (not my own): Abstractions can be classified based on where responsibility lies. Popular languages implementing interface composition expect the caller to know almost nothing about the concrete details while the callee has to handle all concrete permutations. Conversely, the sort of abstraction we see in typeclasses, much like those in c++ template programming, require the client to dictate concrete details that satisfy the callee requirements. Cheers, Darren On 2013-07-01 9:08 AM, "Patrick Browne" wrote:

On 30/06/13, *Dan Burton * wrote:

I am not trying to say "every building is a shelter", rather "anything

...

that is a building must provide sheltering services".

Well if it walks like a shelter and quacks like a shelter... /shrug

One of the nice things about OO is the intuitive nature of the is-a relation between class and instance (forgetting hierarchies for the moment). I suggest that an intuitive interpretation of the Haskell class–instance relation might be *acts-as*. For example, a car or a bus could afford transport once they have a move operation. This is an intuitive view for design; it does not reflect the language level function of handling ad-hoc polymorphism. Also it reifies the type class, which AFAIK does not exist at run time.

Tá an teachtaireacht seo scanta ó thaobh ábhar agus víreas ag Seirbhís Scanta Ríomhphost de chuid Seirbhísí Faisnéise, ITBÁC agus meastar í a bheith slán. http://www.dit.ie This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe