[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Private library symbols...
From: |
Sheldon Gill |
Subject: |
Private library symbols... |
Date: |
Mon, 16 Oct 2006 11:13:24 +0800 |
User-agent: |
Thunderbird 1.5.0.7 (Windows/20060909) |
Hi Richard,
You've made some recent changes to base with the idea of making private
functions in base more obviously private and less accessible.
It seems to be that there is really only one goal with these changes:
applications/tools shouldn't be using private functions in base
Is there any other objective that I'm missing?
If this is the case, I think the approach being taken here isn't the one which
we should be pursuing.
The original situation is we have functions like these:
NSString *GSLastError(int);
BOOL GSEnvironmentFlag( const char *, BOOL );
which make these functions seem like GNUstep API additions but really they are
private.
What has been done is create an "artificial" object
@interface _GSPrivate : NSObject
+ (NSString*) error;
@end
@interface _GSPrivate (ProcessInfo)
+ (BOOL) environmentFlag: (const char *)name defaultValue: (BOOL)def;
@end
Now I say artificial because it doesn't conform to an object design. There
never is an actual instantiation, for example, so you're always sending
messages to the class. There are many other things which make this not really
an object.
Doing this adds many more bytes to the library.
It also makes these method lookups rather than function calls so they are
slower.
So we've added an artificial/strange object, increased the library size and
slowed down those function calls all in an effort to prevent applications using
our private functions. Is this right?
Now its long been idomatic to use the underscore to mark private symbols. In
fact, this is precisely what you've done with the class name.
Further, I think this makes navigating the source harder. Quick, tell me
without searching where you're going to find the implementation for the above
two functions?
Why don't we simply change the functions to conform to idomatic norms?
NSString *_GSLastError(int);
BOOL _GSEnvironmentFlag( const char *, BOOL );
and be done with it?
This won't add to size.
This won't slow things down.
This stays in convention.
If you really want, we could further decorate along the lines of:
NSString *_private_GSLastError(int);
BOOL _private_GSEnvironmentFlag( const char *, BOOL );
although I don't see the point of doing that. I do see some merit in making
these private functions GNU convention
NSString *_gs_last_error(int);
BOOL _gs_environment_flag( const char *, BOOL );
as that is keeping with the style guide.
Further, if the problem is, as you say, "symbol pollution" why not stop the
pollution where it really is occurring: the exports symbol table? Its a linker
problem, not really a source code problem.
Regards,
Sheldon
- Private library symbols...,
Sheldon Gill <=