Uli's Web Site
[ Zathras.de - Uli's Web Site ]
Other Sites: Stories
Pix
Abi 2000
Stargate: Resurgence
Lost? Site Map!
 
 
     home | blog | moose | programming | articles >> blog

 Blog
 
 Archive
 
 Blog Topics
 

15 Most Recent [RSS]

 Less work through Xcode and shell scripts
2011-12-16 @600
 
 iTunesCantComplain released
2011-10-28 @954
 
 Dennis Ritchie deceased
2011-10-13 @359
 
 Thank you, Steve.
2011-10-06 @374
 
 Cocoa Text System everywhere...
2011-03-27 @788
 
 Blog migration
2011-01-29 @520
 
 All you need to know about the Mac keyboard
2010-08-09 @488
 
 Review: Sherlock
2010-07-31 @978
 
 Playing with Objective C on Debian
2010-05-08 @456
 
 Fruit vs. Obst
2010-05-08 @439
 
 Mixed-language ambiguity
2010-04-15 @994
 
 Uli's 12:07 AM Law
2010-04-12 @881
 
 Uli's 1:24 AM Law
2010-04-12 @874
 
 Uli's 6:28 AM Law
2010-04-12 @869
 
 Uli's 3:57 PM Law
2010-04-12 @867
 

More...

Prototype-based programming - where Carbon beats Cocoa

We all know that situation: We want to modify the behaviour of an object, but subclassing won't do, since we get the object handed to us from someone else, and that piece of code can't be told to create a subclass instead of the base class for us.

In some cases, and if we're working in Cocoa, we can go and define a category on such objects to change the behaviour. But of course then we can't call through to the original methods anymore. Apple doesn't like us class-posing, so all we can do in Cocoa is do some ugly low-level stuff like method swizzling ... But that will work on all instances of that class, not on the single one we actually wanted to change.

Recently, Carbon surprised me by solving this Object-Oriented problem better than any of the other Apple-supported OO programming languages:

You see, Carbon is a C API that uses object-oriented paradigms. There's a "base class" called HIObject, and you can "subclass" that by registering additional event handlers (i.e. "methods") on a particular object. The fun thing here is that the virtual method lookup table and instance variables are not kept in one central table for each class. Rather, each object has its own.

The net effect of this is that event handlers and tagged data attached to an object become slots in the way they're used in prototype-based programming. Moreover, Carbon Event Handlers stack. So, if I wanted to change the way my app draws that one particular scrollbar, that is actually part of an HIScrollView, I just find that scrollbar subview and add a second kEventControlDraw event handler to it.

There's no step three... *mad giggle*

Reader Comments: (RSS Feed)
No comments yet
Comment on this article:
Name:
E-Mail: (not shown, hashed for Gravatar)
Web Site URL: (optional)
Comment: (plain text only)
Please Enter the following word:
Or E-Mail Uli privately.

 
Created: 2007-04-05 @933 Last change: 2007-04-05 @993 | Home | Admin | Edit
© Copyright 2003-2014 by M. Uli Kusterer, all rights reserved.