I think you haven't looked deeply at the range of module system designs, and are making a snap decision based on too little information.
With respect to static methods: change your perspective. What's a module? You can look at it as a collection of named, statically typed definitions. Your static methods live here.
But what if you want first-class modules? To compose systems at the module level? Then you need a value of a module type, a way of passing these modules around and parameterizing modules by their dependencies. But we already have a mechanism that looks just like this: objects! So, let our modules be top-level singleton objects, and we get the best of both worlds.
For more along these lines, look at E (capability orientation, with objects representing capabilities) and Newspeak, Gilad Bracha's latest project. Eliminating the ambient authority implied by top-level static namespaces is key behind these (dynamic) systems. But similar approaches are not necessarily restricted only to dynamic systems.
Oh, I fully admit that I'm not up to date with modern module language design, my answer was purely pragmatic - using static methods doesn't seem to have made my code less reusable in any way that's been significant to me, and I write large complex systems in Java. I think that making blanket statements like the OP (checked exceptions are bad, singletons are better than static methods) is a little absurd - Java is for better or worse a pragmatic language and using static methods instead of singleton objects makes my code shorter, clearer and easier to understand to mere mortals. That's a win in my book.
That said, I'm a closet programming language geek so I'll check out your references, thanks for the pointers.
Comments
I think you haven't looked deeply at the range of module system designs, and are making a snap decision based on too little information.
With respect to static methods: change your perspective. What's a module? You can look at it as a collection of named, statically typed definitions. Your static methods live here.
But what if you want first-class modules? To compose systems at the module level? Then you need a value of a module type, a way of passing these modules around and parameterizing modules by their dependencies. But we already have a mechanism that looks just like this: objects! So, let our modules be top-level singleton objects, and we get the best of both worlds.
For more along these lines, look at E (capability orientation, with objects representing capabilities) and Newspeak, Gilad Bracha's latest project. Eliminating the ambient authority implied by top-level static namespaces is key behind these (dynamic) systems. But similar approaches are not necessarily restricted only to dynamic systems.
Oh, I fully admit that I'm not up to date with modern module language design, my answer was purely pragmatic - using static methods doesn't seem to have made my code less reusable in any way that's been significant to me, and I write large complex systems in Java. I think that making blanket statements like the OP (checked exceptions are bad, singletons are better than static methods) is a little absurd - Java is for better or worse a pragmatic language and using static methods instead of singleton objects makes my code shorter, clearer and easier to understand to mere mortals. That's a win in my book.
That said, I'm a closet programming language geek so I'll check out your references, thanks for the pointers.