Re: Future Objective-C changes
Re: Future Objective-C changes
- Subject: Re: Future Objective-C changes
- From: Marcel Weiher <email@hidden>
- Date: Wed, 21 May 2003 10:02:05 +0200
<CodingHorror>
class MyGraphicsContextSaver
{
MyGraphicsContextSaver( NSGraphicsContext *gc ) { [gc
saveGraphicsContext]; }
~MyGraphicsContextSaver() { [gc restoreGraphicsContext]; }
}
Then in my Objective-C++ method I could write:
- (void)drawMyObject
{
MyGraphicsContextSaver gcs;
DoSomeStuffWhichMightThrowExceptions();
}
</CodingHorror>
Actually, the first time I saw this construct, I thought: Wow! How
cool is that!
On further examination, and having absorbed Kent Beck's Best Practice
Patterns, it struck me just how awful this sort of code is.
Talking bout non-intention-revealing code! How much more obscure can
you get than an *automatic variable declaration* causing a global state
change. Let me say it again: you are simply declaring a local,
automatic variable, but what you are *intending* to do is modify some
global state.
Yep, it has some 'interesting' properties, but the price is just too
high, there must be other ways of achieving the desired effect.
[snip]
If Objective-C++ is the future, then integrating the exceptions
mechanisms is essential.
This may be the case, but I haven't actually seen a crucial need for it
in my last 15+ years of Objective-C hacking.
If Objective-C is the way to go, then an extension to move towards the
functionality of smart pointers would be nice. It might solve issues
with reference counting (which aren't difficult once you master them,
but definitely error prone),
Hmm...I don't find it error prone. If you use convenience factor
methods for temporary objects, then the only place you need to deal
with reference counting is the accessor. If you use accessor-macros,
the accessors, and especially the refcounting that goes on inside them
essentially disappears, and the whole thing is automatic (apart from
dealloc, but that is so straightforward/boiler-plate that it just
disappears in the other syntactic noise of creating a class).
So I don't quite see what smart-pointers would add, except for overhead
because they generally have to refcount on every assignment, right?
issues with dealloc (I often forget to invoke [super dealloc]), and
other assorted memory leak problems.
Tip: when you write your dealloc method, start it off like this:
-(void)dealloc
{
[super dealloc];
}
Only then start to add your local deallocation.
Imagine that you could write code like the following:
- (void)myThread
{
smart_pointer<NSAutoreleasePool> pool = [[NSAutoreleasePool alloc]
init];
my_thread_code();
}
And [pool release] would guarantee to be called no matter what
exceptions were thrown in my_thread_code()!
Not sure what that would bring me, since threading is pretty rare, and
if there are exceptions, I would want to know about them anyway, so I
need to put in my handler and then putting the pool-release code
outside is no big deal either.
I'd rather have that sort of stuff explicit rather than magical, I
think. The tiny amount you save when typing is, IMHO, far outweighed
by the obscurity that results.
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.