• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Future Objective-C changes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future Objective-C changes


  • Subject: Re: Future Objective-C changes
  • From: "Clark S. Cox III" <email@hidden>
  • Date: Wed, 21 May 2003 07:56:33 -0400

On Wednesday, May 21, 2003, at 04:02 US/Eastern, Marcel Weiher wrote:

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

The only real alternative:

- (void)drawMyObject
{
[gc saveGraphicsContext];
try
{
DoSomeStuffWhichMightThrowExceptions();
[gc restoreGraphicsContext];
}
catch(const someExceptionIWantToHandleLocally &)
{
[gc restoreGraphicsContext];
}
catch(...)
{
[gc restoreGraphicsContext];
throw;
}
}

Note that you have to have three calls to [gc restoreGraphicsContext]; (actually one plus one per exception handler and one per return statement). This leads to very hard to maintain code. If you use a stack-based utility class, you only have to declare it once, and you've basically enclosed that function in a protective bubble, you've just guaranteed that after you leave the current stack frame for any reason, you've properly reset the global state.
This type of stack-based utility class is quite logical and straight forward. You want to mack some change, but only have it persist for the current stack frame, what better way than to tie the actually setting/resetting of that state to entering and leaving the stack frame?


--
http://homepage.mac.com/clarkcox3/
email@hidden
Clark S. Cox, III
_______________________________________________
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: Future Objective-C changes
      • From: Quentin Mathé <email@hidden>
    • Re: Future Objective-C changes
      • From: Marcel Weiher <email@hidden>
References: 
 >Re: Future Objective-C changes (From: Marcel Weiher <email@hidden>)

  • Prev by Date: NSOpenGLView drawing
  • Next by Date: Re: Future Objective-C changes
  • Previous by thread: Re: Future Objective-C changes
  • Next by thread: Re: Future Objective-C changes
  • Index(es):
    • Date
    • Thread