> Matt Rice wrote: > > I'm not going to say it's impossible with type classes but without inheritance, > I'd really have to get a few thousand lines of code in and see how it turns out. > > but like shap I have somewhat of an interest in at least modeling something > in bitc based loosely on a system of inheritance >
Even though I think type classes will do it all ( and like some of you would like to do a few thousand lines of real code ) , it has a number of issues that can be improved. - Learning curve , see the Haskell articles like "Type classes made easy" . This means it is intimidating for them and may be a reason for Haskell slow adoption especially by B programmers. I do understand them now , but knowing when , how and optimally using them is still difficult for me.. - Better support for C++ /C#/Java programmers coming across. - Interop with OO Libs - Can be more intuitive to code which can help productivity. Type classes to me ( which may be because I'm in inexperienced) seem to require a lot more thought and planning . In terms of planning they are more like templates this means you can produce great libs but it requires a lot of work and thought when sometimes you just want to write quick code. Though I think rather than inheritance , interfaces are a better way to do this since -They map better to type classes and encourage fewer methods / functions. - They are easier to break apart and prevent code degeneration by lesser skilled developers. ( Note your issue above in breaking it up ) . With inheritance you will see massive difficult to refactor classes. - Tests and Mocks work much better . - The Multiple inheritance issue ..so either you support it or interfaces also . - They provide better opaque types so we don't need to introduce object access control etc ( which is needed for inheritance since you do want to restrict some base class functions and not others) - Can be a nice short cut for a type class always referring to a boxed type. As already stated the only disadvantage is that you don't get the shared code of the base class but this is often described as an advantage since your not introducing base code bugs and if needed you can use a shared method via type classes. Why am I stating interfaces but not inheritance ? I just think interfaces as a stepping stone has some merit and still fits in nicely as a language with a goal of writing more "pure" code. Inheritance goes too far towards being just another OO language and hence type classes become questionable ie with inheritance you have objects and hence OO , with interfaces this does not need to be the case at all. I'm not touching the explicit downcast issue as that should be a different thread. Ben _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
