Re: Private library symbols...

[Richard Frith-Macdonald]

On 18 Oct 2006, at 01:10, Sheldon Gill wrote:

> Well, you  actually are relying on conventions anyway. You've  
> called the class _GSPrivate using the underscore convention to  
> indicate privacy.

Sure ... as I said, I used a variety of mechanisms ... to be as safe  
as possible.

> Also, these are private function calls within the library.  
> Encapsulation doesn't really apply here.

I don't see why you say that ... encapsulation is a principle to  
enhance maintainability which applies at various levels.  It breaks  
large problems down into smaller ones and you need to get very small  
indeed before it's unimportant.

> Conventional layout has private functions near the top of the  
> source file, just after header includes. They aren't that hard to  
> find. Especially if you keep to convention with the underscores.

I think this statement is a good point in support of trying to use  
language features in addition to conventions ... since your notion of  
'conventional layout' is by no means universal.  I'm not even sure  
that putting private functions 'near the top' is conventional at all  
other than in as much as you need to declare something before you use  
it.  Many people prefer to put declarations as close as possible to  
the place they are first used.
I'm all in favour of using conventions to aid maintainability ... but  
I don't believe in relying on a single convention (which may not be  
universal) when other mechanisms can be used too.

> As to the leading underscore, that is used by C and Objective-C and  
> extensively within -core. Who is going to be working with the code  
> who doesn't know the language? Are you advocating that we change  
> the way -core is written so that its easy for those not familiar  
> with the language?  That we should eschew idiom and use different  
> approaches to facilitate that?

No, I'm talking about working *with* those conventions and enhancing  
them ... and making things work with the Objective-C idioms more than  
the C idioms.

> And what is the real problem with the global symbols? Are you  
> suggesting that people look through the library symbol table and  
> choose methods/functions based on what they find there?

That certainly happens with proprietory code ... and while I see no  
good reason for people to do that with open source code, I expect  
that they will apply the habits/techniques they have developed when  
working with other systems when they come to program with GNUstep.

> And that it is an issue for -core maintainers to address?

Sure ... not a big issue, but why not take account of it.

> > What would be involved in this?  If we *can* remove symbols  
> > effectively without breaking the library's internal use of them or  
> > impairing debugging, it would probably be good to do so.
>
> Try:
>
> $> strip

I can't find any option in the manual for strip to selectively remove  
information so that some functions can't be linked to ... and  
removing all symbol information would certainly impair debugging.  Am  
I missing something obvious?

> Just to be clear, I'm all for improving the code for reading,  
> navigation and maintenance. I simply disagree that this class  
> wrapping is the right way to do it. We can achieve all those goals  
> without the class wrapper.

Yes ...but a class wrapper is a natural way to do it for ObjC  
programmers ... really the only reason for doing it that way rather  
than functions in a dispatch table for instance (which would achieve  
all the other objectives).