Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


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


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.


> 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: