[I am sorry I did not pay enough attention to this old thread at that
time. (See https://savannah.gnu.org/bugs/index.php?30766#comment19
for why this is relevant now.)]
At Sun, 6 Sep 2009 17:56:34 +0100,
Richard Frith-Macdonald wrote:
1. we don't want to expose internal workings because we don't want
developers to start to depend on those internals in such a way that
it's hard for us to change things later without breaking existing
applications.
2. we don't want to expose internal workings because changes to them
may break API and mean that apps need to be recompiled.
Issue 1 is real, but we can't quantify how important it is as it's a
amatter of perceptions rather than a true technical issue. Luckily
it's quite easily largely fixable, simply by removing pthread.h form
the header and replacing the types from pthread.h with opaque dummy
types of the same size, so that there is no temptation for developers
to use them directly. So I did that, though really, I'm not sure that
was worth the bother, since the ivars concerned were already clearly
marked as private.
As they're marked as @private, there's no way for developers to access
them in subclasses, right? Only the size matters for the purpose of
subclassing. So I fail to see what the issue is, and how including a
specific header and using library types in ivars for a *required*
library (configure bails out if pthread is not found) is "exposing
internal workings".
I guess it's just good to do it to avoid having the extra symbols
polluting developers namespaces.
I admit I don't understand this.
Issue 2 is a technical problem ... if someone subclasses one of the
lock classes, their compiled code is obviously dependent on the size
of the superclass and if that size changes (eg due to using a
different pthread implementation) then the size of the superclass
would change even though the version of the base library is
unchanged. So potentially an app linked with one copy of the base
library would fail to run properly with another copy of the library
even though it was the same version!
If the different pthread implementation is ABI incompatible, that
would mean that gnustep-base (and anything else using this new pthread
implementation) *must* be rebuilt. Two different incompatible
implementations on one platform can only coexist if they have
different SONAME.
So, if Base is rebuilt because the size of, say, pthread_mutex_t is
different (i.e. ABI change in pthread), then config.status will
substitute @GS_PTHREAD_MUTEX_T@ to the new value, achieving what
... the compiler would do automatically with David's code before that
change.
If Base is not rebuilt (for whatever reason -- user/distro omission
for example), the opaque type will not help at all, because gs_mutex_t
would still have the wrong size -- it would match the size of
pthread_mutex_t at the time Base was compiled. The class size will
not match the actual size at runtime, possibly leading to the breakage
the trick was intended to avoid.
In conclusion, I think this change serves no purpose and doesn't make
*anyone's* life easier. I may be wrong, but it seems to me that using
directly pthread types in ivars does no harm at all, in practice.
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep