Emulating CLOS-like :around methods in Scala

[BalmungSan]

@jimka

I rejected the ADT-via-sealed-class approach because I don’t want all my code in a single file.

Again, the idea is that you have just data in one file and computation in others.
That is one of the main differences between OOP and FP, OOP wants to combine data and computation in a single entity, FP wants to split those.

But as I have said a couple of times, if you like your approach then ok.
It just seems that trying to keep with it always produce further problems.

@jimka

BTW, I don’t know Haskell. Do you know if the Haskell solution also requires the user to put all the code in one single file?

No, because again they would just put data in one file and logic in others.

@jimka

I rejected it because I don’t understand it well enough.

This is valid, I also reject the subclassing approach because I really can not understand how a code that jumps from one file to another, form one subclass to another, and from the son to the parent to the grand-parent to the son to the son’s son is understandable

@jimka

I had lots of trouble to convert the type class code from scala 2.12 to 2.13.

Not sure how typeclass would have had troubles with this? There is nothing in that migration that affects traits and implicits AFAIK. Maybe something related to custom collections?

@jimka

And I have nightmares about trying to eventually convert it to 3.x.

Code using typclasses in 2.13 will compile just as it is in 3.0 and if you want to use the Scala 3 features then, that is just replacing a couple of keywords.
Extension methods would do require a bigger change but nothing to be worried about.

@jimka

To me the concept of implicits obfuscates type class related code. Type class code which I’ve written did not (for me) express the intent, but expressed language constraints which to me looked like leaky abstractions. As I understand, Scala 3 attempts to alleviate some of this obfuscation.

Yeah, the new keywords try to better express intent but the pattern is the same.
IMHO, if you didn’t understand it in Scala 2, then Scala 3 won’t help much really.

---

@Jasper-M

You can separate the “bodies” of your leaf classes into separate files: Class, trait, impl in different *.scala files?

That didn’t work out well because OP no only needs to separate the implementation.
He also needs passing constructor parameters, calling super implementation and many other things that at the end make the code very complex.

[jimka]

@Jasper-M

You can separate the “bodies” of your leaf classes into separate files: Class, trait, impl in different *.scala files?

I tried this, on a branch. I eventually abandoned it because it was even more complex than before. Admittedly I did find a couple of bugs in my code during that pursuit, bugs related to matching not exhaustive. So it has merits. But eventually, I decided I was creating extra classes just to satisfy the compiler.

[sangamon]

@jimka

Do you know if the Haskell solution also requires the user to put all the code in one single file?

No, just as Scala doesn’t. In Scala, functionality can either go into methods of the ADT cases or in functions that dispatch over ADT cases via pattern matching - the latter can go in arbitrary external files. Haskell doesn’t have methods at all.

@jimka

With regard to the type class approach (which fundamentally is independent from the ADT approach). I cannot judge whether this approach would fit my needs or not.

Type classes loosely correspond to OO interfaces - they declare an abstract API that can be implemented by multiple types. This is mostly independent, indeed, and whether you want to use them will depend on whether your “algebra” should be polymorphic across multiple ADTs/type hierarchies.

@jimka

Additionally, in my mind the problem I’m trying to solve really is object oriented—despite the Scala object system’s limitations and java legacy.

And that’s what I personally fail to see - evaluations over an expression tree are often used as introductory examples for ADTs and FP. There are problems that look inherently suited to OO to me, but these immediately conjure ideas about message passing and encapsulated, mutable state, and I can’t spot this here. (Which doesn’t mean that an OO approach is inappropriate, it just doesn’t feel more natural than FP at all.)

[jimka]

@BalmungSan

Not sure how typeclass would have had troubles with this? There is nothing in that migration that affects traits and implicits AFAIK. Maybe something related to custom collections?

I think the problem was that some of the functions I was using and some of the class names I was references were deprecated. However, to figure out how to update the code, I had to again look at the typeclass code which I didn’t understand.

Your point about that the code would still work is probably correct. I.e., it is not absolutely necessary to refactor deprecated code. But I did it in order to satisfy all the compilation warnings, and to be a good Scala citizen.