On 10 Mar 2009, at 16:49, Xavier Glattard wrote:
I'm sorry, i still can't see any problem.
I'll try to explain this in simple words then:
- If two classes use this mechanism in the same inheritance chain,
then they will have overlapping ivars, unless you add even more
complicated code to work around this. Complicated code leads to
debugging problems.
- Third-party classes expect the extra bytes mechanism to work. Your
idea breaks NSAllocateObject() on any subclass of a class that uses
this mechanism. If class A uses this mechanism, and (third-party)
class B subclasses A then calling NSAllocateObject() with some extra
bytes on B will appear to work, right up until you call a method
inherited from A which tramples over the data you've tried to store
after B's instance.
- Accesses to these extra ivars require an extra layer of indirection
which will be as slower than non-fragile ivars and much slower than
normal ivars.
- Some things rely on being able to introspect the ivars using runtime
functions, your idea breaks this.
In short, it is a vaguely academically-interesting idea, but is not
suitable for general use and would cause far more pain than it would
eliminate. It is fragile and even if it works initially it will
eventually result in code that is unmaintainable.
David
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev