Re: isa
Re: isa
- Subject: Re: isa
- From: Marcel Weiher <email@hidden>
- Date: Sun, 2 Jun 2002 10:16:06 +0200
On Saturday, June 1, 2002, at 10:53 Uhr, Aram Greenman wrote:
On Saturday, June 1, 2002, at 01:15 AM, Marcel Weiher wrote:
On Friday, May 31, 2002, at 11:57 Uhr, Aram Greenman wrote:
Previously on this list we were discussing how to get an object to
behave like a class one or more steps up in the inheritance hierarchy.
The problem was accessing overriden functionality of superclasses, and
there is an easy way to get this without any tricks whatsoever, just
good coding practices.
Instead of having a method
-doStuff // class A
{
lots of interesting stuff happens here
}
which you then override with in a subclass with:
-doStuff // class A' subclass of A
{
do my subclasses interesting stuff
}
and then not being able to access this in A''
-doStuff // class A'' subclass of A'
{
how do I get the original A implementation? -> you can't!
}
simply split this out into two methods
-doStuffA // class A
{
lots of interesting stuff happens here
}
-doStuff // class A
{
[self doStuffA];
}
now A' can override to its heart's content, A'' can still easily
access the original A method
-doStuff // in class A''
{
[self doStuffA];
}
Done.
But, you ask, how do I do this when doStuff is defined in a system
class that I don't have source code for? Easy. You just have to do a
bit of lateral thinking. Simply define a new selector, -doMyStuff
and use that instead. For the system class you want to use,
implement -doMyStuff { [self doStuff] } in a category.
My way is easier ;)
No it isn't. No smiley.
The only reason this looks long is that I presented it very thoroughly.
The problem can be solved using a simple helper method that is a good
idea anyhow. There is no need to go raping and pillaging through the
runtime.
I also suggested changing the object's isa temporarily, with the
disclaimer that it might be a bad idea.
It is a very bad idea, especially the temporary swizzling.
Exactly how? That is my suspicion, but I would like to know
specifically why it is a bad idea.
Unintended and unforseen side-effects. The point is that the problems
are difficult to forsee precisely, because the assumption that the isa
pointer is correct is a very basic assumption that is made throughout
the system. Messing with it essentially means that code somewhere will
break, either now or in the future, possibly depending on execution
paths rarely taken.
IMNSHO, it is akin to asking what exactly will happen when writing data
to an uninitialized pointer. Bad things.
[foo performSelector:@selector(bar) asClass:[Baz class]];
it would be pretty hard to get confused about what your intent is.
The problem is that the system will be confused while it is doing this
particular message-send.
The other, maybe bigger, problem is that if you even *want* to do this,
you are ignoring a message that your code is trying to tell you very
loudly: I am organized incorrectly!
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
- Follow-Ups:
- Re: isa
- From: Aram Greenman <email@hidden>
- Re: isa
- From: Marco Scheurer <email@hidden>
| References: | |
| | >Re: isa (From: Aram Greenman <email@hidden>) |