Classy structs: inheritance and polymorphism on top of structs

Your Libraries & OS Mentoring Libraries
1

Hi all,

I made a tiny macro library that adds object-oriented features, such as inheritance and polymorphism, on top of structs.
Github: https://github.com/timmolderez/classy-structs
Hex: https://hex.pm/packages/classy_structs

Let me know what you think :slight_smile:

Cheers,
Tim

8 Likes
2

This is a really cool example of what you can do with DSLā€™s in Elixir nice job!

If only we could convince you to use your powers for good! :wink:

3 Likes
3

Haha thanks :stuck_out_tongue:

Not to worry, most of the Elixir code I write still is functional, but I found classes to be a good fit for one specific case.

If youā€™re interested in the details: Iā€™m working on this research project that lets you do machine learning in distributed systems, and it should be easy to plug in additional machine learning algorithms. I first implemented these algorithms with structs + protocols. Eventually my code was full of defdelegates to ā€œinheritā€ functions, and it got a bit messy to keep a separate struct for all fields that are common to all algorithms. Maybe thereā€™s a better way to do it, but Iā€™m happy with classes so far :slight_smile: (You can actually see the commit that refactors the structs+protocols to classes here: https://gitlab.soft.vub.ac.be/smileit/marlon-dsl/commit/339fb1d02c26b7ac88abcd4eb2e0a684e31a6bd3#9af9cee2b42b228e6488ab965fe8db2044c824a0 )

1 Like
4

It is a lot neater (the diff).

I guess there are always use cases for these things I was just being facetious :stuck_out_tongue:.

1 Like
5

Hey @timmolderez. I do not have a time yet to look enough deeply, but this reminds me another project called oop. Can you say if itā€™s similar and if so what a difference you have regarding to first one?

1 Like
6

Hey Eiji,

The oop project does provide a similar feature set, but theyā€™re quite different under the hood.

My intent with Classy structs is to provide object-oriented features, while sticking as close as possible to vanilla Elixir. In particular, class instances are directly represented as structs, which means class instances are immutable and all fields are public.

I think the intent behind the oop project is more to show that you can do full-blown OOP in Elixir. If I understand correctly, the oop project represents class instances as GenServers, which is what makes it possible to have a mutable data structure and private fields.

2 Likes
7

Yeah this sounds like entirely the wrong usage of protocols. This actually sounds like the stock erlang/elixir domain of Behaviours and First-Class Modules. I.E. you make a behaviour that the MLAlgo modules need to follow, and you pass the name of the MLAlgo modules around and call functions on it instead. Protocols are for dynamic dispatch based on data, Behaviours and First-Class Modules are for dynamic dispatch based on a module. :slight_smile:

2 Likes
8

Iā€™m not sure if it would make a difference in the end. Each of these MLAlgo modules indeed implement a behaviour, but theyā€™re also a data type. (because each MLAlgo represents what it has learnt so far in its own kind of data structure) Itā€™s hard to keep them separated in this case :slight_smile:

9

This would be a perfect case for tuple-calls, if only Elixir and OTP both were not trying to break themā€¦ >.>

But are you needing to ā€˜dispatchā€™ on the data type though is the question? You could of course carry them around in a tuple regardless since you know all calls will involve them. :slight_smile: