Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Composition over inheritance shouldn't be a dogma since inheritance is really a form of composition. It allows the composition of a class implementation/interface from multiple other classes. Obviously composing code without using the provided language features for virtual dispatch can be more flexible, however inheritance has the advantage of being able to succinctly define types that are just parametrizations of other types.

  class SortedList
    cons(var key=(i) -> i)
  
  //Does it really matter if you write

  class AgeOrderedPeople extends SortedList
    key(person)
      person.age

  //or

  AgeOrderedPeople = partiallyApply(SortedList, key=(person) -> person.age)
when trying to parametrize behavior?

What's truly ironic is when people who blindly denounce inheritance then proceed to write things like

  sorted_people = people.sort((p) -> p.age)
inline, in 12 different places or slightly better

  sorted_people = (people) -> people.sort((person) -> person.age)
Java and C++ have their faults, but I'm not really sure what's wrong with C#, since it's probably the best designed of the current statically typed languages that have mainstream adoption. It has the right mix (if a little OO biased) of OOP and FP, awesome reflection (using a special type interface an AST can be captured at compile time from a lambda expression), a powerful generic system (covariant, contravariant, generic constraints, method type inference, works at the bytecode level), properties, local type inference, syntactic sugar for generators, syntactic sugar for limited continuations (essentially break methods in two, the request code and the response callback while coding it as if it were synchronous), and a fairly sane library. And all of the slides apply to C#, which in mundane but complicated code bases is probably much more productive than the sexier languages out there.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: