On Wed, 2004-08-04 at 10:12, Peter Moulder wrote:
On Tue, Aug 03, 2004 at 11:11:40PM -0400, MenTaLguY wrote:
Yes, I would prefer that any new "methods" be added as real C++ methods.
I'm not sure what is meant by `"methods"' above,
I did mean member functions; I was feeling a bit illiterate last night. ^^;
but these days I tend to prefer non-member functions over member functions:
- Information-hiding principle suggests that if a function doesn't need access to private variables then it's better not to make it a member function.
Mixed feelings. I would mostly agree, though obviously polymorphism usually requires virtual member functions, which ought to be private or protected.
In some cases (e.g. "message sending") methods and certain types of mutatiors, I think a member function is also better for clarity.
In any case the specific functions under discussion were relatively simple accessors.
- Member functions must be declared in the class definition, which tends to require more recompilation because one can't use a separate header file.
IMO this should also be addressed by breaking large classes into smaller, simpler classes that do more specific things (and can get their own header files).
A related issue is that it's harder (impossible) to write private specializations: any specialization must be declared in the class definition too, so it isn't private other than through comments.
I'm not sure I follow ... are you referring to template specializations?
The shorter names typical of member functions are harder to search for.
(Counter-argument: this is a matter of custom, there's no technical reason why one can't use long names for member functions, or even short names for non-member functions.)
Whether member or no, I would encourage folks to spell words out and make names as long as necessary to avoid ambiguity (but no longer than that).
This brings up a related rule of thumb -- if it seems necessary to include a class' name in a function name, that function is probably better off being a member function (or at least split into member and non-member parts).
One additional disadvantage of member functions is that getting pointers to them is unweildy; the syntax for working with pointer-to-member-functionis awkward and the type itself can be very heavy-weight.
So I do prefer non-member functions on the basis that they are more easily composable via function pointers.
It might have been better for me to qualify my request as pertaining to specific kinds of functions (e.g. accessors), but I'm not quite sure exactly where the line lies. At this point it's a matter of taste that I've not managed to formalize well yet.
What I specifically don't want to see is more non-member functions like sp_object_get_whatever() or sp_object_set_whatever() introduced.
-mental