"Jonathan M Davis" <jmdavisp...@gmx.com> wrote in message news:mailman.1680.1310785695.14074.digitalmar...@puremagic.com... > > joinPath: > I'm not sure that this function should be renamed to joinPath. When > discussing > other modules such as as std.ascii and std.uni, we decided that they > should > have the same function names and _not_ put the module name in their names. > Now, this function _is_ joining paths, so it's not purely a case of having > the module's name in the function name, but I'm still not sure that we > want to > have it as joinPath instead of join. >
I really, really, REALLY, *REALLY* think it's a big mistake to categorically ban using the module name in the function names. And its *especially* bad in this case. Having both std.algorithm.join and std.path.join with their different semantics is just begging for problems. "join" is a terrible, terrible, awful, horrible name for this function. I don't care if using conflicting names between std.ascii and std.uni was deemed OK. Every case needs to be judged on its own or else we're knee-deep in bondage & discipline design and we may as well call ourselves "Sun Microsystems" and our language "Java". And yes, the precedent set by std.ascii and std.uni is a factor in the decision, but I think the rest of the situation here easily overrides that concern. Hell, when people see "join" they think of the semantics of std.algortihm.join, *never* "Oh, 'join' means using path separators." And looking at the names of the arguments, or other context clues, isn't a valid counter-argument because when I see "join(path1, path2, filename)" I'm going to immediately think "bug, or at least overly fragile". And why not? From the name "join", I have no way to tell. I don't give a crap about "Ext" vs "Extension" (they both get the job done), and I think that horse has already been beaten to death last time std.path was discussed. But calling joinPath "join", is bad, bad, bad, bad, BAD.