David Chisnall a e'crit :
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
I understand your arguments, and I thank you for your efforts to use
simple words for my simple mind. But once again my suggestion was for
internal use only, as the external ivars are today. Where external ivars
works, my system should work (maybe with some minor modifications).
That was just an idea. Take it or leave it.
-- Regards
--- Xavier
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev