On 18 Oct 2006, at 11:46, Matt Rice wrote:
this can also be done by using the
__attribute__ ((visibility ("hidden")))
function attribute found in the gcc info page..
requires gcc 3.something and not available on all
platforms, but,put putting a define in there such as
#define GS_HIDDEN ""
for those platforms should deter usage
because of the threat that most platforms used wont
link coupled with the fact that the functions are not
declared in any installed header files..
That's great ... exactly the sort of thing I've been looking for!
I checked various versions of the gcc documentation online, and it
looks like this was introduced at 3.3 and is still present in 4.1
i haven't really looked into whats been done, but find
the definition of private a little ambiguous wrt scope
e.g.
private methods/functions for a classes internal usage
i like to keep these as static functions...
Yes ... functions only used within a single file should always be
static.
I think private methods should be declared in a private category and
use an underscore prefix (and be kept to a minimum).
private methods/functions to be used by other classes
in the same library,
This is the case that the visibility attribute is perfect for
(functions), and I suppose private methods should use the same
conventions as those for internal use within a single file ... the
only difference would be that the files inside the library need to
share a common header to declare the library-private categories.
I've put GSPrivate.h in base/Source for this.
private methods to be used between libraries like the
gui/back backend stuff..
I'm not sure we should consider gui/back interaction private ... I
think we actually want a public API for this, which people can use to
implement otyher backends.
all which imho warrant different solutions...
anyhow, toss me in the 'prefers private functions'
boat
Well, your suggestion of the visibility attribute removes my biggest
reason for using methods rather than functions.
I think remaining reasons are rather a matter of taste ... do we
want to use ObjC semantics or C semantics generally?
Do we care whether we group functionality in a class, or use a
collection of functions with a common prefix?
Do we want to use a single style or both functions and methods?
My personal preference (but it's not a strong one) would be to group
functionality in classes rather than have a lot of methods anyway,
but to use private (ie visibility hidden) functions where there might
be a performance issue.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
