Re: [RFC] Header organization GNUstepBase

[Alexander Malmberg]

Nicola Pero 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.
> 
> Our source is free and open, theirs is proprietary and obscured. :-)

True. :)

> > 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?

Short answer: No.

Long answer:

The "fragile base class"/"user must know the instance size"
problem/feature is a consequence of how the language is implemented in
gcc. Hacking around this in a library is the Wrong Thing; it's ugly and
cumbersome, it adds complexity in the wrong place, it's inconsistent
with how objective-c is supposed to be used, and it would make
conventions in user code inconsistent with the library, so we'd need
more hacks and more complexity (for eg. key/value coding).

If "we" (objective-c users in general) really wanted to fix this, it
should be done by fixing it in gcc and the gnu objective-c runtime. This
could be done, but involves some kind of trade-off.

It could be done with a minor change of language semantics (to make them
invisible to users; if that isn't necessary, semantics don't have to be
changed), and it would give us completely private ivars (that don't have
to be visible to users, and that can be changed without breaking
subclasses; there'd still be public ivars, but they would still have
restrictions). It would cost at least a small amount of memory, at least
a small amount of performance (how much memory/performance depends on
the exact solution), and a lot of complexity (in the runtime and in the
low-level parts of -base).

Given that the gains are small in a free software/open source world, I
don't think the change would be worthwhile.


> No, I don't think it would be better in terms of preventing people from
> using them.  Prefixing them with underscores is enough.  If you want, you
> can add a 'Please do not access ivars directly' comment at the beginning
> of each class ivar listing.

In many cases, we could (and possibly should) also make the ivars
@private. I agree that the underscore==private convention is enough,
though we might want to document this somewhere clearly.

[snip]
> The only reason why it might be better to store the ivars in a separate
> struct is to prevent a change in the ivar layout from breaking binary
> compatiblity.
> 
> Whenever you add or remove an ivar from a class, all subclasses need to be
> recompiled.  This can be annoying, and it is particularly important for
> the core libraries which are used everywhere - on the other hand, most
> base classes are very rarely subclassed,

If by "base classes" you mean base/, that's probably true. Subclassing
is probably more common in -gui, especially of NSView.

> so this problem is honestly not
> that important.  Also, the ivar layout doesn't change so often - when was
> the last ivar layout change ?

It has happened and it has broken things a few times, but not recently.
Anyway, that's why we have versioned libraries. Besides, eventually -gui
will be finished (at least I'll do what I can to prevent creeping
featurism), the classes and ivars will be stable, we'll release 1.0, and
there won't be a problem. :)

- Alexander Malmberg