I'm sorry that this will come across as rude, but I feel like you're repeating something you've heard but didn't quite understand.
In my previous post I hinted that the name of the function should "describe what the function does", which is the same as "describe the intention of the function", because if the function doesn't do what it's intended to do, that's a bug.
If we're representing beverages as strings which are somehow guaranteed to begin with "co2" if the beverage is carbonated, and we've decided that the deserialization should be mixed into your "high-level, in your business domain", the program is so badly written that we're not going to get any truths about good programming from it
if is_carbonated(beverage):
beverage.jiggle(false)
if beverage.startswith("co2"):
beverage.jiggle(false)
> Why a function that takes an Actor instead of each Actor being a type that implements a receive function?
That function is a method with receiver type `Actor` - IE `Actor` implements this HandleMessage function.
Granted it is exactly equivalent to ``` func HandleMessage(a *Actor, from gen.PID, message any) error { ... } ```
But I'm happy sticking with composition over inheritance