Donkey code

I don't think your comparison makes sense. The power of the "name it Steve" philosophy is the same rationale behind adopting codename for projects: it helps create a context to disambiguate discussions. As part of Steve, you work on the Steve web app and on the Steve service. The Steve service later can be refactored to peel out one of Steve's microservices listening to Steve's message broker.

Later if Steve needs to consume data from Pluto, you know that Steve's service will chat with Pluto's service, and perhaps have Steve's message broker listen to some channels in Pluto's message broker, etc etc. Zero ambiguity.

Moreover, monoliths have a propensity to outgrow responsibility-driven names. With a monolith you might start with a widget service, which then handles transactions, inventory, and order history. Once any of those responsibilities is peeled off to a microservice, do you still have a widget service along with a widget inventory service? Is it ok to keep calling widget service the widget service if it only handles widget order history?

While I agree with much of the sentiment about clear naming, I think that many languages with OO capabilities fail to provide easy to use role based composition at their peril. It is a big challenge to do wrestle real code and we need all the tools we can get.

Here's how it could look with roles at a coarse grain level:

---

role Breedable { ... }

role Feedable { method eat-carrot { ... } }

role Trainable { ... }

class Horse does Breedable does Feedable does Trainable { has $.sound = 'neigh'; ... }

class Donkey does Breedable does Feedable does Trainable { has $.sound = 'heehaw'; ... }

my $h = Horse.new(); $h.eat-carrot();

---

The benefit of roles is that they let you apply your human language skills (English, French, etc) to combine words as in natural languages - so roles are akin to Adjectives and classes to Nouns, and method names to Verbs.

With roles, you can avoid the temptation to hardwire inheritance:

---

class Donkey is Horse { ... }

---

And it leaves open the option for layers of specialization of roles like this:

---

role DonkeyTrainable does Trainable { ... }

class Donkey does Breedable does Feedable does DonkeyTrainable { ... }

---

And you can use inheritance and role composition side by side:

---

class Beast Breedable does Feedable does Trainable { ... }

class Horse is Beast { ... }

class Donkey is Beast { ... }

---

Here's what it says in the docs: _Roles are a collection of attributes and methods; however, unlike classes, roles are meant for describing only parts of an object's behavior; this is why, in general, roles are intended to be mixed in classes and objects. In general, classes are meant for managing objects and roles are meant for managing behavior and code reuse within objects._

btw these examples are in raku ... https://docs.raku.org/language/objects#Roles

I think of these kinds of names as being like primary key fields in a database: Their main purpose is to distinguish the identities of various things, so it's better not to incorporate any functional/behavioural description into them because that way there's never a need to change the name in the future if the behaviour changes.

The downside is that the names become arbitrary lumps of data that you have to become familiar with by rote use.

.. there are fertile mules. Rare, but they exist.