[javcasas]

Not everything can be associated to a single entity. Many operations work on two or more entities where none of them are the "master". Otherwise you end up with "coordinators".

Users.create(...) is the easy case. Try transfer_permissions(user1, user2, entity) while retaining transactionality and the ability of either user to cancel the transfer.

[elric]

Permissions.transfer(x, y, z)

I'm not sure why having a global function by the same would make this any easier or harder to implement. But it would pollute the global namespace with highly specific operations.

[javcasas]

And now you have invented a helper class when all you needed is a namespace. And you already had namespaces.

[elric]

It doesn't have to be a class. It can be an interface. And regardless of what it is, it has to go somewhere. Whether it's in assorted_functions.c or Permissions.java makes little difference.

I mean it makes sense to group "like" things together. Whether that's in a module, a class, an interface, or a namespace. Having a huge number of things globally is just confusing pollution.

[javcasas]

> it has to go somewhere

Yes, but going as a static method into a class that goes into a module is overkill vs just putting it in the module.

> Having a huge number of things globally is just confusing pollution.

I don't know what language you use, but modern programming languages allow specifying what to import when importing a module. You don't have to import everything from every module.