Proposal for std.path replacement

[spir]

On 03/04/2011 12:01 PM, Jonathan M Davis wrote:
>> I have a preference for the longer names, but not a very strong one.  I'm
>> >  not going to oppose the changes if others agree with you.
> I definitely like descriptive names, and my function names are often long, but I
> do tend to find that long names can get annoying - especially if you have to use
> them often. So, I think that you should generally choose shorter names as long
> as they are appropriately descriptive. A name like stripExt is clear enough -
> especially in context - to work quite well, so the longer name stripExtension is
> unnecessary, whereas ext may not be clear enough and the full name extension

I tend to agree with you.
Especially on the point that (very) common names can be shorter. On one hand, 
they are more easily inderstood & memorised precisely because they are common; 
on the other, you get the maximum benefit in terms of user-friendliness for the 
same reason (that they are common). Abbreviating more rare names makes the code 
harder to understand for (very) few benefit.
Now, is stripExt/stripExtension that common? I would say no. The day you need 
it, you may have to write it several times because you're dealing with a piece 
of code that copes with file names. Right, then, you may like it be shorter. 
But this "pain" will soon stop; and maybe, probably?, you won't have again to 
write that name for weeks or months. What do you think?

Another factor is the inherent clarity of the abbreviation. 'ext' can certainly 
be interpreted in various ways. As you say, context helps much; but it's a 
decisive argument for languages in which context prefixes, such as module 
names, are commonly used: eg "path.stripExt(fileName)". But this is not common 
practice in D, thus func names need be more precise, I guess.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com