A late-night rant about OOP and parametric dispatch
devblog.avdi.org
A late-night rant about OOP and parametric dispatch
1–10 of 33 posts
Re: A late-night rant about OOP and parametric dispatch
#2The author has no idea what “parametric polymorphism” means. It's not “dispatching on all the arguments to a function”.
Re: A late-night rant about OOP and parametric dispatch
#3This seems weird to post here. It's clear he's working out some ideas, but hasn't gotten them clear enough in his head to take out of context and discuss in a place like HN.
Re: A late-night rant about OOP and parametric dispatch
#4I don't really see a pervasive point to this rant. It is true that OOP can be reduced to message passing, and that there's a specific style of OOP a lot of people see as "OOP", but that doesn't mean that this style is "just obfuscated procedural code, or uglified functional code". That OOP can be implemented on top of functional style code, or procedural style code says nothing about it being "true OOP" or not. For example, the great Common Lisp Object System is built with functional primitives. And that makes it more elegant, not less. Building an object system on top of a functional/procedural language is syntactic sugar, and there's nothing inherently bad about it. After all we write code for people to read.
Re: A late-night rant about OOP and parametric dispatch
#5The issue to me is one of name spacing. Where is the XML#to_s defined? Certainly not in one very large to_s function that takes in large swaths of various types. Of course it should be namespaced around XML, the only issue is whether it's module based or object based.
I think object based is better. Why? Because I can take the object and introspect the methods. Any number of functions can take in an XML object, but there are very few methods that the XML object needs to have. In my repl if I do:
my_xml.methods - Object.new.methods
functions.collect { |f| f.first_argument_can_be? XML }
Now, you could argue that all method-like functions should be namespaced to their own module, but now humans have to be trusted to not define these functions outside of that module and they have to be trusted to not define anything else in the module. For what purpose?
Re: A late-night rant about OOP and parametric dispatch
#6What was so urgent about getting out this half-baked thought out that the dude couldn't have waited to write something coherent?
If all you're doing is calling methods on objects with no supertypes or private members, then yeah, you could accomplish the same thing by convention. But once you start layering on more functionality in your object system, the number of way you code encode this functionality starts to explode. Everybody ends up doing things their own way, and there's no consistency or compatibility. Sound familiar? It should because it's C.
Re: A late-night rant about OOP and parametric dispatch
#7The issue to me is one of name spacing. Where is the XML#to_s defined? Certainly not in one very large to_s function that takes in large swaths of various types. Of course it should be namespaced around XML, the only issue is whether it's module based or object based. I think object based is better. Why? Because I can take the object and introspect the methods. Any number of functions can take in an XML object, but t…
It's not a binary choice. You could easily have everything be module namespaced and then then allow module functions to be selectively promoted to method invocation. But really, that's no different from requiring all functions to be methods and then selectively 'demoting' some to be static or class functions instead.
Re: A late-night rant about OOP and parametric dispatch
#8This seems weird to post here. It's clear he's working out some ideas, but hasn't gotten them clear enough in his head to take out of context and discuss in a place like HN.
It does not seem to have been posted by the author.
Re: A late-night rant about OOP and parametric dispatch
#9Consider this tree:
dog
bark
softly
loudly
run
fast
slow
cat
meow
purr
run
To be formal you can pick out the code by saying `(do dog bark loudly)`, where `do` is a reduction that concatenates and executes the code at each node. (With a little constraining you could say `(do-special loudly)`)
OOP just calls these API coordinates by special impressive-sounding names. The top level "objects" and the second level "methods" and the third level "method arguments", and imposes all kinds of finicky constraints (some of which are even useful). Languages differ wildly with these constraints: Java doesn't let you have a unique instance method (well, not without either reflection or bytecode manipulation, anyway), but Ruby does (lovingly called "monkey-patching"). And it's quite rigid in it's current form, with a fixed noun/verb/adverb structure.
At the end of the day all that detail obscures the simple truth that your code defines a coordinate system and an invocation is a single coordinate. There's a lot more to be said about this, of course! But I hope it helps/inspires.
Re: A late-night rant about OOP and parametric dispatch
#10The issue to me is one of name spacing. Where is the XML#to_s defined? Certainly not in one very large to_s function that takes in large swaths of various types. Of course it should be namespaced around XML, the only issue is whether it's module based or object based. I think object based is better. Why? Because I can take the object and introspect the methods. Any number of functions can take in an XML object, but t…
Elixir is a functional language, and has the option of modules and protocols so you can define XML#to_string in two ways.
Either as a protocol so you could do to_string(this_xml)
Or as a function within the module so you could do XML.to_string(this_xml)
If you use the module function defintion you can import it into your scope via import XML
then you can write to_string(this_xml) as if it were a protocol.