This feels like a very “Javascript” question. Just because most member functions in javascript are function(self,args…)… And usually can be called statically or on an instance… And in both cases, they work the same. (unless the function behavior takes execution into account)
But even Javascript always has some sort of scope. (i.e. in a browser, global is actually window) There’s no real parallel in Java because you don’t have a globally shared scope.
I think lessons learned in modern Javascript are that using namespaces for everything is the way to go. And I think that applies here.
By creating the setYear(obj,int) function, are you now committing to support this function for all possible object types? Not just java.util.Date, but Joda derivatives, cfc’s that might contain a setYear function - and are you then going to support different arguments based on the implementation? Is xxxx(obj,…) implicitly under the hood going to be mapped to obj.xxxx(…)? That could lead to wildly unpredictable behavior.
I’m with Igal. Member functions are member functions. They properly support encapsulation, are “namespaced” or at least limited in scope, and operate on objects with a well defined contract. (i.e. now().setYear() might mean something entirely different from someDAO.setYear()) I don’t think it’s a good idea to say a global setYear(date, year) function will only work on dates - it just enforces bad programming practices and the expectation that other supplied objects will work too. Nor is it a good idea for the language to assume responsibility for doing reflection so setYear works on anything.