On 2009-04-12 21:34:47 -0400, Daniel Keep <daniel.keep.li...@gmail.com> said:
Michel Fortin wrote:
Which makes me think of one thing: why "isBounded" instead of plain and
simple "bounded"? Ranges don't respond to "isEmpty": they have "empty"
instead.
I think it is time to establish some kind of standard for naming things,
and then follow it. Something a little like Cocoa's Coding Guidelines
comes to mind:
<http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html>
You
mean http://digitalmars.com/d/1.0/dstyle.html ? That said, the
"Naming Conventions" section is actually about formatting names, not
choosing them.
Nice.
Indeed, I think there should be a section about choosing proper names
in that document.
One major advantage Cocoa has over D is that argument names seem to be
part of the function's name. For example, this call:
sendAction(aSelector, anObject, flag);
appears to be written like so in Objective C:
[sendAction: aSelector to: anObject forAllCells: flag];
To be honest, there are times I almost wish we could not only name
arguments on the caller side, but demand that they're named in the
definition.
void sendAction(SEL, Object to, extern bool forAllCells);
sendAction(aSelector,
to: anObject, // optional
forAllCells: true); // required
It works in Cocoa because it's part of the method name (the actual
method name for the above is "sendAction:to:forAllCells:").
Your idea doesn't work well with function overloading and passing
function arguments using tuples. In D, the method mangled name includes
the argument types to support that, so you can use an enum instead and
get mostly the same result:
enum ForCells { ALL, SELECTION }
setAction(aSelector, anObject, ForCells.ALL);
Hum, that'd be a good pattern to add to a programming guideline document.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
