Next in Review Queue: The New std.path

Jonathan M Davis jmdavisProg at gmx.com
Fri Jul 15 22:22:14 PDT 2011


On Saturday 16 July 2011 01:10:02 Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> news:mailman.1680.1310785695.14074.digitalmars-d at 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.

Well, like I said, I'm not sure that naming it joinPath instead of join is a 
good idea, but I'm not sure that it's a bad idea either. In this particular 
case, path is not only the module name, but it's actually what's being joined. 
So, I'm not entirely comfortable naming it joinPath, but I'm not entirely 
comfortable naming it join either.

I think that the general decision to not put module names in function names 
needs to be brought up in this case, since that is essentially what is 
happening here, but it may very well be that this is a case where we should 
not follow that general rule.

- Jonathan M Davis


More information about the Digitalmars-d mailing list