Re:Classes are a way of writing higher order functions
by azangru on Wednesday September 09, 2020 @01:34PM
(#24423502)
> This problem (calling functions defined god-knows-where) is not unique to OOP as opposed to FP
Well, part of that problem is solved by explicitly importing functions from individual modules, at which point you know where exactly your function is coming from.
> when your 'foo' function gets a 'frob' function passed to it as a parameter, it's anyone's guess what actual function it may be
Part of it is probably solved by static typing. The other part is that it shouldn't pose a problem, much like you probably don't have a problem passing all sorts of frobs to your map-s, and your filter-s, and your forEach-es, and your then-s
You place the cursor at 'getScore' and press F12. This problem (calling functions defined god-knows-where) is not unique to OOP as opposed to FP.
> How do you know which part of your code is responsible for the number of this.rockets and how many methods in how many classes can change it?
You place the cursor at 'rockets' and press Shift+F12. This problem (modifying/passing data around god-knows-where and what parts) is not unique to OOP as opposed to FP.
> How do you find out which part of your code is going to call the launchRockets method,
See above.
> and whether this will even be this class's method or one of its children's?
Well, there is Ctrl+F12 that shows you different (re)implementations of the method.
> How many hops across your codebase do you need to make to figure all this stuff out?
About three to four. Again, this problem is not unique to OOP as opposed to FP: with FP, when your 'foo' function gets a 'frob' function passed to it as a parameter, it's anyone's guess what actual function it may be. To find all possible cases requires you to find all call sites of your 'foo' function, but that's non-trivial since it is most likely has also been passed around as an argument under different names.