On Fri, 29 Oct 2004, Johannes Waldmann wrote:
A remark on naming: I don't like names like "absolutizePath".
The "Path" suffix in fact expresses type (resp. module) information, and I would think that it is typical for languages *without* proper type resp. module system to force programmers to simulate them by mere naming conventions.
yep
So I would suggest to use qualified names (Path.absolutize).
*me too*
Of course that's seems to be a general problem, for instance, with insertFM, lookupFM. But then, the FiniteMap module is much older than hierachical namespaces. But for Paths, the point is designing a new library, so we should use the best techniques available.
I really advise to take a look at Modula-3. There, not only every function name omits the information of the type, even more each module has the name of the type it describes and the main type has the name T. In Modula-3 this convention is essential for template modules. This doesn't introduce new problems because module names have to be unique. So the user of a library can choose if he wants to use a short unqualified function name, some abbreviated module name for qualification or the full module name. I started to use this style for my Haskell modules, too, e.g. http://cvs.haskell.org/darcs/numericprelude/physunit/PhysicalValue.hs I'm still uncertain what identifier to use for constructors and type classes.
In fact it's only one technique, qualified names - the other candidate would be a type system that allows static overloading...
If you don't propose the way C++ does it ... :-) But how can overloading be cleaner than type classes?