Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

Post by BubRoss » Sun, Oct 20, 2019, 3:27 AM UTC

tome wrote: post #33

colllectorof wrote: post #15

>In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus. This correctly identifies one of the worst problems with how people construct OO programs when they get out of college. They are infected with the idiotic desire to make neat taxonomies. They don't know why. They can't even explain the rules that make one taxonomy good and another one bad. They just feel some immense pres…

> 3. Often you want to use the default protocol implementation with some changes. Instead of re-implementing the rest of the protocol, it's highly convenient to be able to specify only the differences. > #3 is the core reason why inheritance was developed. No, absolutely not. As sibling comments say, composition is sufficient for that. I can only see exactly one reason why inheritance is necessary: to allow superclas…

Post by userbinator » Sun, Oct 20, 2019, 3:43 AM UTC

colllectorof wrote: post #15

>In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus. This correctly identifies one of the worst problems with how people construct OO programs when they get out of college. They are infected with the idiotic desire to make neat taxonomies. They don't know why. They can't even explain the rules that make one taxonomy good and another one bad. They just feel some immense pres…

Post by smrq » Sun, Oct 20, 2019, 6:42 AM UTC

couchand wrote: post #94

colllectorof wrote: post #76

Earlier quoted context omitted.

Firstly, late binding is orthogonal to inheritance. It simply means that methods are looked up based on runtime information, rather than determined at compile time. You can have late binding in a language with no inheritance or classes at all. Secondly, OO composition does not solve the problem I described in #3. If object X has 9 methods I want to reuse in object Y, making X a component of Y still requires me to re-…

> If object X has 9 methods I want to reuse in object Y, making X a component of Y still requires me to re-implement those 9 methods in Y, even if they are just pass-throughs. That is also not universal. In Ruby, for instance, one can write: class Y def method_missing(m, *args, &block) @x.send(m, *args, &block) end end

Post by tome » Sun, Oct 20, 2019, 9:29 AM UTC

colllectorof wrote: post #76

tome wrote: post #33

Earlier quoted context omitted.

> 3. Often you want to use the default protocol implementation with some changes. Instead of re-implementing the rest of the protocol, it's highly convenient to be able to specify only the differences. > #3 is the core reason why inheritance was developed. No, absolutely not. As sibling comments say, composition is sufficient for that. I can only see exactly one reason why inheritance is necessary: to allow superclas…

Firstly, late binding is orthogonal to inheritance. It simply means that methods are looked up based on runtime information, rather than determined at compile time. You can have late binding in a language with no inheritance or classes at all. Secondly, OO composition does not solve the problem I described in #3. If object X has 9 methods I want to reuse in object Y, making X a component of Y still requires me to re-…

Post by wowthisanacct » Sun, Oct 20, 2019, 2:52 PM UTC

callmeal wrote: post #59

xyzzyz wrote: post #49

Earlier quoted context omitted.

Not sure what you mean, exactly. Could you sketch a simple example with some types and typeclasses?

This is how it would be done in Java: class Parent { public void first() {}; public void second() {}; public void third() {}; } class Child extends Parent { @Override public void third() {}; //change implementation of third function, reusing the first two. }

  data Numberable = Numberable {
    first  :: IO ()
   ,second :: IO ()
   ,third  :: IO ()
  }

  parent = Numberable {first = return (), second = return (), third = return ()}

  child = parent { third = print 'third' }

  data Env = { numberable :: Numberable }

  doStuff :: (MonadIO m, MonadReader Env m) => Int -> Int -> m ()
  doStuff num1 num2 = do
    myNumberable