6 ms·

OOP is not much more than single-dispatch runtime polymorphism. The benefit of `data.sort()` is you could write that in a function that accepts a `data` that c

OOP is not much more than single-dispatch runtime polymorphism. The benefit of `data.sort()` is you could write that in a function that accepts a `data` that could be an array, a vector, a linked list, etc... anything that implements the "sortable" interface. Writing `Array.sort(data)` in your function means the function won't be usable for any kind of data other than arrays. The other features of OOP like encapsulation, inheritance and abstraction -- these aren't so special. But OO polymorphism is pretty unique.

mrkeen 6y ago
I hadn't thought of interfaces (e.g. sortable) as being an OO thing. That said, I do sometimes confuse myself trying to use them in Java, e.g. void foo() { Fruit[] basket = new Apple[] { new Apple(), new Apple() }; handleFruit(basket[0]); } void handleFruit(Fruit fruit) { System.out.println("Do I get called?"; } void handleFruit(Apple apple) { System.out.println("Or do I?"; } If it were runtime polymorphism I'd expect it to dispatch to the apple method, but it dispatches to the fruit method. I also run up against friction trying to define, e.g. the "mappable" interface across these two guys. Can't seem to get it done. class Optional { <U> Optional<U> map(Function<? super T,? extends U> mapper); } class Optional { <R> Stream<R> map(Function<? super T,? extends R> mapper); } For what it's worth, Java went with the polymorphic Collections.sort(data) approach, not the polymorphic data.sort() approach.
- tpxl 6y ago
  >Collections.sort(data) approach, not the polymorphic data.sort() Since java 8, java.util.List had a sort method and Collections.sort(List) just calls List::sort. Before that, only the Collections.sort method existed. At least from java 6 on, java has a SortedSet and SortedMap that accept comparators as constructor parameters, but have no sort methods (So basically data.sort, not collections.sort(data)). Arrays can of course only be sorted via Arrays.sort, since arrays have no methods.
- _old_dude_ 6y ago
  Java like C++ or Swift uses single-dispatch polymorphism, so only the receiver (the argument before the '.') is used at runtime. In Java, you can implement your own dispatch table quite easily Map<Class<?>, Consumer<Fruit>> dispatchTable = Map.of(Apple.class, fruit -> handleFruit((Apple)fruit)); Fruit fruit = basket[0]; dispatchTable.get(fruit.getClass()).accept(fruit);
  - pjmlp 6y ago
    In C++ you can fake multi-dispatch, by making use of templates, templates specialization and overloading though. It is just somewhat cumbersome.
dnautics 6y ago
> But OO polymorphism is pretty unique It's not. Julia uses multiple dispatch so that you can use the same * operator on integers, floats, complex numbers, quaternions, matrices, matrices of quaternions, galois field elements, and then it's sophisticated enough that if you implement a new type with +, -, /, etc. you can get matrix solving from the standard library for free. So you just implement + - * / on the GF(256) and you can do reed-solomon erasure repair, hell, in quite optimized code trivially without rewriting LU decomposition. Other FPs have solved the polymorphism question in their own ways as well (protocols are a common scheme).

mrkeen 6y ago

I hadn't thought of interfaces (e.g. sortable) as being an OO thing. That said, I do sometimes confuse myself trying to use them in Java, e.g. void foo() { Fruit[] basket = new Apple[] { new Apple(), new Apple() }; handleFruit(basket[0]); } void handleFruit(Fruit fruit) { System.out.println("Do I get called?"; } void handleFruit(Apple apple) { System.out.println("Or do I?"; } If it were runtime polymorphism I'd expect it to dispatch to the apple method, but it dispatches to the fruit method. I also run up against friction trying to define, e.g. the "mappable" interface across these two guys. Can't seem to get it done. class Optional { <U> Optional<U> map(Function<? super T,? extends U> mapper); } class Optional { <R> Stream<R> map(Function<? super T,? extends R> mapper); } For what it's worth, Java went with the polymorphic Collections.sort(data) approach, not the polymorphic data.sort() approach.

tpxl 6y ago
>Collections.sort(data) approach, not the polymorphic data.sort() Since java 8, java.util.List had a sort method and Collections.sort(List) just calls List::sort. Before that, only the Collections.sort method existed. At least from java 6 on, java has a SortedSet and SortedMap that accept comparators as constructor parameters, but have no sort methods (So basically data.sort, not collections.sort(data)). Arrays can of course only be sorted via Arrays.sort, since arrays have no methods.
_old_dude_ 6y ago
Java like C++ or Swift uses single-dispatch polymorphism, so only the receiver (the argument before the '.') is used at runtime. In Java, you can implement your own dispatch table quite easily Map<Class<?>, Consumer<Fruit>> dispatchTable = Map.of(Apple.class, fruit -> handleFruit((Apple)fruit)); Fruit fruit = basket[0]; dispatchTable.get(fruit.getClass()).accept(fruit);
- pjmlp 6y ago
  In C++ you can fake multi-dispatch, by making use of templates, templates specialization and overloading though. It is just somewhat cumbersome.

dnautics 6y ago

> But OO polymorphism is pretty unique It's not. Julia uses multiple dispatch so that you can use the same * operator on integers, floats, complex numbers, quaternions, matrices, matrices of quaternions, galois field elements, and then it's sophisticated enough that if you implement a new type with +, -, /, etc. you can get matrix solving from the standard library for free. So you just implement + - * / on the GF(256) and you can do reed-solomon erasure repair, hell, in quite optimized code trivially without rewriting LU decomposition. Other FPs have solved the polymorphism question in their own ways as well (protocols are a common scheme).