Delphi to Cocoa

Concept Comparison

Though the concepts are largely the same, a lot of the Objective-C terminology is foreign. Here is a list of terms and concepts as they appear between the two languages. This will be updated and changed over time, so I’m presenting this as a page, not a post.

Last Updated: 28 Dec 2007


Delphi Objective-C Notes
class class object Class definitions are actual objects at run-time. One can do interesting tricks with them.
object object an instance of a class
method name selector e.g. insertObject:atIndex: (colons are part of the method name)
static binding dynamic binding
strong typing looser typing (C-derived)
method invocation sending a message
nil nil
Self self
inherited super
RTTY type introspection
Boolean BOOL
True YES
False NO
abstract There are no abstract classes in the Delphi sense. Any mention about abstract classes in the documentation are purely conceptual.
class variable (∄) There are no class variables in either language. Use static global variables in the implementation section.
interface protocol
a class implements an interface a class adopts a protocol and conforms to the protocol “adopt” means to list in the class declaration. “conform to” means to actually implement the methods. NOTE: This implies that one can create a non-conforming class in Objective-C. To Delphi, this is a compiler error.
call back method delegate Note that the name and signature of the callback on the class must match the delegate name and signature, then call [otherObject setDelegate:self]; in the init() method.

Working With Classes

Delphi Objective-C Notes
  lFoo :class of TObject;
  lFoo := TBar;
Class foo = [Bar class];
TObject (class type) NSObject both use single-rooted hierarchies
TObject (variable type) id untyped object reference
  lFoo: IInterfaceName;
id  lFoo;
untyped interface reference
if A is TFoo
if([a isKindOfClass:Foo])
is “a” an instance of this class or a descendent
if A.ClassName='TFoo'
if([a isMemberOfClass:Foo])
is “a” an instance of this specific class
[object method]
Shape.SetOrigin(10, 20)
[shape setOrigin:10 y:20]

[shape setOrigin:10 :20]
The colon separates parameters, but it’s normal to use named parameters. Oddly, the first parameter doesn’t seem to have a name?
[[Foo alloc] init]
alloc only does raw allocation of the class. init calls the constructor (in rough Delphi terms)
[Foo initWithParameter:bar]
One uses “initialization methods” — convenience constructors — which begin with the four characters “init”.
AfterConstruction initialize
Supports() conformsToProtocol This is a method on all classes.
Create init As in Create, call [super init] first.
NOTE: “Correct” form of initializers is different.
self = [super init];
if(self != nil) {
[self setFirstProperty:foo];
[self setSecondProperty:bar];
return self;
This is the “correct” form of initializers since the parent init may return nil or a object different than the receiver. (Hillegass p. 72)
Destroy dealloc As in Destroy, call [super dealloc] last.
if Assigned(Foo) then Foo.Bar; [foo bar] The if Assigned(Foo) then check is done automatically. If Foo is nil, then Bar won’t be called.
GetFoo foo Note that property accessors do not have “get” in the front. The method name does not conflict with the field name.
SetFoo setFoo property mutator
if aValueFValue then
FValue = aValue;
[aValue retain];
[FValue release];
FValue = aValue;
This is a sample simple property mutator implementation. This Objective-C is the simplest, and works even if the same object is passed in. See Hillegass pp. 66-67.

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at

%d bloggers like this: