gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Header organization GNUstepBase


From: Nicola Pero
Subject: Re: [RFC] Header organization GNUstepBase
Date: Sun, 3 Aug 2003 12:14:39 +0100 (BST)

> Sounds right to me.
> But this reminds me of a side issue I keep meaning to bring up...
> 
> 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. :-)


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

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.  I've never heard of someone using those ivars
directly thinking they were public, so I don't recognize this as a problem
anyway.  They might be using them knowing they are private and they are
risking messing things up - they have the right to do so if they want :-)

Generally, in my experience spending time in enforcing access control in
software is not a particularly good idea anyway.  If access to private
data/code is a problem, writing clear documentation saying that ivars
should not be accessed seems a better way of spending time.

It also looks like it would make our source code more difficult to read
and to understand.  I imagine that would work having a single ivar which
is really a pointer to another separate structure, which is allocated when
the object is allocated, and which keeps the actual ivars.  Wouldn't that
also slow down things by perfoming an additional malloc() call each time
you allocate an object, and an additional free() call each time you
deallocate an object ?  This might slow down things considerably for cases
where you allocate/deallocate many small objects.

It might also give a bad example - storing ivars as ivars (and not as a
separately allocated structure) is generally a good thing to do.  Not only
is more efficient, but it permits key/value coding to work, for example.

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

Anyway, these are only my comments - if you still feel (after considering
pros and cons) that it's a good thing to do, I guess you might go on.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]