> Here's a simple example: > > - (void) dealloc > { > [someIvar release]; > [super dealloc]; > }
It's worth noting that even in C++ there's a special case for delete, so that one can write "delete myptr" rather than "if(myptr) delete myptr)" 10 bazillion[1] times. I was around when this behavior was standardized, and there were people arguing strenuously that this would support "sloppy programming", whereas my opinion is that writing redundant code unnecessarily is what is sloppy. > That makes a lot of sense. I can now picture many lines of code I've > written over the years which wouldn't have been necessary with this > feature. Here's an example from my own use. Imagine a "workflow" type application. You'd have some kind of big chunk of structured data (probably backed by database, but that's irrelevant here). At various stages in the process, you would show different subsets of the details to different users, using different forms from different nibs. Approach 1: different window controller for each form. Lots of common code for handling controls is duplicated between forms. Approach 2: extract code for common controls into a base class. Each form has its window controller that inherits from the base class and implements the non-common controls. There is the possibility that either some forms still have duplicated code, or that to eliminate duplicated code requires more than one level of inheritance (yuck!). But the biggest problem is that as requirements change, some controls may change from being common or not, and the code may have to be moved around in the hierarchy. Approach 3: put code for all controls in the base class, and count on the fact that controls that don't exist in a nib will have their outlets set to nil, and messages to them will be noops. There *may* still be some cases where you will need to know if a control actually exists, but in most cases you simply don't need to know. (Bindings change the balance, because they eliminate a lot of code that interacts with controls.) [1] Yeah, yeah, yeah. Templates, Boost, Loki: modern C++ code should have far fewer explicit invocations of delete than what we were writing back in the '80s. -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.com/ (303) 722-0567 voice _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]