Re: [RFC] Header organization GNUstepBase

[David Ayers]

Hello,

Sorry for the delay, I'm currently visitng my Berlin-family, and I've 
busy for two day trying to rid their computer of viruses and ad 
servers.  I now know the definition of an infected PC :-( ! It's still 
isn't fully freed of malware, but now I've been able to make it fairly 
usable and install mozilla so I don't have to deal with the web 
interface of my provider through IE, and actually I'm able to respond to 
mail.

I'll try to check my mails for urgent issues, but probably won't reply 
to to many messages for about a week, until I'm back home.

Richard Frith-Macdonald wrote:

> If you look at Apples headers, you will often see classes with no ivars,
> wheras we have loads of ivars in the interfaces we declare in our 
> headers.
>
> We normally prefix all our private ivars with an underscore to tell 
> people
> not to use them in any subclasses they might write, but wouldn't it be 
> better
> to hide them completely like Apple do?
Well, I'm not sure what Apple's motivation is, whether it's obfuscation 
or compatibility.  It's clear that changing the layout/size/amount of 
ivars always imposes compatibility issues in ObjC, but I think we are a 
lot less affected by it than Apple because most of our "users" compile 
their projects from source.  Yes, it might be annoying sometimes to 
recompile all your code just because a new version of -base/-gui, but I 
think it's manageable and acceptable given the fact that we are still 
actively developing and evolving our libraries.  It would be different 
if the binary packaging of our releases and those of our "users" 
dramatically increased.

I think from a developer point of view, If you wish to use the @public 
and the @protected ivars of super classes, their use should be obvious 
and if you can read the source, I see nothing wrong with subclasses 
accessing them (of course we should always discourage modification, and 
I wish ObjC had a feature to enforce that... but that's getting [OT]).  
If we don't want subclasses to acces out ivars (read only) because of 
internal state / consistency issues, we should simply declare them @private.

Now for GNUstep/OPENSTEP/Cocoa compatibility I've been wavering back and 
forth about whether or not the @privat and @public ivars (not 
necessarily their layout) isn't actually part of the interface we should 
try to be compatible with.  When porting  to GSWeb I often find customer 
code that has very intimate knowledge of these ivars (and private 
methods) and this always calls for added special handling.

I always found it very helpful to look at header files to understand how 
a class works and how to use it.  Of course you also learn how to abuse 
it.  But I think for variables, that we don't intend for subclasses to 
have access to, declaring the @private should be the guide line.

I think a potential transition from @private variable to completely 
opaic headers would still be OK at some later point in time, if we ever 
deem it useful (i.e. increased binary packages.)

But as we have an active "learning" community, I think such special 
messures would just make it harder to analyze code and we should avoid that.

Cheers,
David