However, as I was writing this blog post, it became obvious to me that I needed something better than Shape/Rectangle toy explanations. I needed to build something real. So I decided to build a test framework.
I wrote a quick explanation of the design I was using here: https://gitlab.com/mikekchar/testy/blob/master/design.md You can read that first if you just want to see what I was doing and don't want the long winded explanation of how I got there from the blog post.
I suppose TL;DR: Objects should not represent ADTs. Instead they hold state. The object is really a collection of operations on that state (bundled together to give you better cohesion). The state is encapsulated in the object and should be inaccessible except through the operations. Objects should probably be immutable as well -- especially as it enforces that encapsulation. The best way to think about it is that the object itself is a monad (and it literally is). The methods on the object are functions that you would normally pass to bind. The "." that does the dispatch is essentially bind. I found that I never actually reached for subclass polymorphism (even though it was easy to implement). Instead I used essentially traits and I think this is in keeping with the modern idea that OO should encourage composition over inheritance.
Why do this instead of FP? Well, as you can see, my code is really FP with "FP Objects". I think the thing I liked about this is the idea that the objects created a nice abstraction for cohesive code. It's not that different than type classes (and I always think it's funny that type classes are usually implemented with virtual function tables). However, it is slightly more restricted in terms of generic functions. In a system without static type checking, I think it's easier to reason about this code. YMMV.
In the end, I found this way of programming very enjoyable. The code is still quite crufty, so please don't judge me ;-) I was just writing it to explore the ideas. It's not production code.
I considered going on and finishing Testy and possibly building something else with that style of programming, but it turns out that all current implementations of JS are quite inefficient when using closures (and may even leak memory!), so I decided to work on something else.
If you have any questions or comments, feel free to fire away.
I started out by deciding to write a blog post. Here is my rambling second draft: https://github.com/ygt-mikekchar/oojs/blob/master/oojs.org#r...
However, as I was writing this blog post, it became obvious to me that I needed something better than Shape/Rectangle toy explanations. I needed to build something real. So I decided to build a test framework.
Here it is: https://gitlab.com/mikekchar/testy
I wrote a quick explanation of the design I was using here: https://gitlab.com/mikekchar/testy/blob/master/design.md You can read that first if you just want to see what I was doing and don't want the long winded explanation of how I got there from the blog post.
While I was writing this code, I decided to make a coding standard for myself because sometimes it helps to add constraints to examine how things are working. The coding standard is here: https://gitlab.com/mikekchar/testy/blob/master/coding_standa...
I suppose TL;DR: Objects should not represent ADTs. Instead they hold state. The object is really a collection of operations on that state (bundled together to give you better cohesion). The state is encapsulated in the object and should be inaccessible except through the operations. Objects should probably be immutable as well -- especially as it enforces that encapsulation. The best way to think about it is that the object itself is a monad (and it literally is). The methods on the object are functions that you would normally pass to bind. The "." that does the dispatch is essentially bind. I found that I never actually reached for subclass polymorphism (even though it was easy to implement). Instead I used essentially traits and I think this is in keeping with the modern idea that OO should encourage composition over inheritance.
Why do this instead of FP? Well, as you can see, my code is really FP with "FP Objects". I think the thing I liked about this is the idea that the objects created a nice abstraction for cohesive code. It's not that different than type classes (and I always think it's funny that type classes are usually implemented with virtual function tables). However, it is slightly more restricted in terms of generic functions. In a system without static type checking, I think it's easier to reason about this code. YMMV.
In the end, I found this way of programming very enjoyable. The code is still quite crufty, so please don't judge me ;-) I was just writing it to explore the ideas. It's not production code.
I considered going on and finishing Testy and possibly building something else with that style of programming, but it turns out that all current implementations of JS are quite inefficient when using closures (and may even leak memory!), so I decided to work on something else.
If you have any questions or comments, feel free to fire away.