Talk:Objective-C

Domain

objective-c.org's ownership is still lost, at least October 2002 through March 2003. If it becomes relinked, please fix it. Otherwise be warned it is one of those casino ads+list of searches pages. -User:Geoffrey

Title of article

The programming languages master list(s) seem to be switching the primary page names to <language> programming language, meaning "Objective-C" should probably be changed to "Objective-C programming language", which currently is redirected. Brent Gulanowski 19:40, 24 Oct 2003 (UTC)

Read Wikipedia:Naming conventions (languages) and the talk page carefully to see why this doesn't have " programming language" added. There are some who favor adding it always, but they're probably Pascal programmers. :-) :-) Stan 21:03, 24 Oct 2003 (UTC)

Validity of disadvantages?

The listed disadvantages are somewhat questionable: Garbage collection, Operator overloading, Multiple inheritance, and C primitive types not first-class objects

Given the purpose and use of Objective-C, these features are certainly of questionable benefit. In addition, comparison to C#, Java, or Python is particularly unfair, as the languages are intended for considerably different purposes.

I may agree with GC, OO, multiple inheritance, but not having some sort of treatment of C primitive types as first-class objects can be downright annoying at times, though I can understand completely why it's not done so. Dysprosia 08:56, 12 Nov 2004 (UTC)

Clarifications

Among other clarifications, I deleted the following section, because most of it addresses attributes of the Mach-O runtime architecture/file format, not the Objective-C language itself. Other than delegation and remote invocation, none of the following is or was specific to Objective-C. NeXT machines did have some of the first widely available shared library support, and did support multiple architectures in the Mach-O file format (circa NeXTstep/OpenStep 4.0), but none of these runtime features were intimately bound with the Objective-C language.

Other features

ObjC in fact included a laundry-list of features that are still being added to other languages, or simply don't exist at all. These led from Cox's (and later, NeXT's) realization that there is considerably more to programming than the language. The system has to be usable and flexible as a whole in order to work in a real-world setting.

Delegating methods to other objects at run-time is trivial. Simply add a category that changes the "second chance" method to forward the invocation to the delegate. Presto!
Remote invocation is trivial. Simply add a category that changes the "second chance" method to serialize the invocation and forward it off.
Swizzling allows for classes to change at runtime. Typically used for debugging where freed objects are swizzled into Zombies, whose only purpose is to report an error when someone calls them. Swizzling was also used in EOF to create database faults. Swizzling is used today by Apple's Foundation Framework to implement Key-Value Observing.
All libraries are dynamically linked. This meant that large Objective-C programs were in fact quite small, because the library was already on the machine. Common today perhaps, but this is from the early 1980s when dynamic linking was fairly rare.
Libraries can be supplied in multiple versions in a single file. Applications can choose to use a specific version (4.3.2), the latest version (which happens to be 5.2.1), or even the latest of a particular major release (anything from 4.x). Versioning problems like this continue to haunt other systems to this day, including Java and component object model.
Code can be provided in multiple object formats for different platforms, in a single library. This avoids the need for a virtual machine entirely. Typical multi-platform Objective-C programs are smaller than most single-platform programs on other systems.
Archiving. An object can be archived into a stream, such as a file, and can be read and restored on demand.

I had reverted this (for an accidental reason), but this material still is relevant, as Objective-C is not just the language, but the runtime as well. We can probably lose the multiple object format comment, however. You admitted yourself that delegation and remote invocation are part of the language, so these were replaced, as with swizzling and archiving, which are also part of the language. Dysprosia 07:25, 14 Nov 2004 (UTC)

Getting better all the time

If there was ever proof that the wiki "works", this article is it. I wrote the first draft over a period of a few days and now I see it has been greatly expanded and much more readable.

Some comments:

1) the reason I mentioned the library format in this article is that I felt that it went hand-in-hand with the reusability issue. Without a good library system reusability is often reduced to cut-n-paste of source code. I agree it was not at all clear that there was a distinction, however, and perhaps the article should include a section on these issues under a "ObjC in Next" type heading?

2) Multiple inheritance is one of the features that I find sorely missing from ObjC. Whenever you actually dig into the implementation details, you find that the REAL reason a language doesn't include it is that it makes the classloader more difficult to write (sometimes lots). However this simply moves the problems off of them and onto us.

3) I think GNU's implementation of GC deserves some expansion, as I believe they did it cleanly and in a very usable manner. IMHO, Apple would do well to simply copy it outright.

Any comments here? Should I just dive in?

Maury 13:22, 1 Dec 2004 (UTC)

In response to Maury

Being a newbie to Objective-C, but a big fan, I would offer the following opinion

perhaps the article should include a section on these issues under a "ObjC in Next" type heading?

These are perhaps better left to the articles on Cocoa (software), or NeXT, under the history section. The NS* object framework is a vendor-supplied library, and not like a "standard library" in the C sense. Then again, I wonder how many ObjC newbies like myself would agree with the statement "delegation is trivial" if NSObject didn't come shrinkwrapped with the -delegate and -setDelegate: methods.

Apart from this, I think there are two main points about reusability, unrelated to what library you use...

You can use C sources in the middle of your Objective-C project without porting, something you absolutely cannot do with C++.
You can add methods to a class without subclassing it or having the implementation source code available to you. This feature, as I understand it, is unique to ObjC and its mom, Smalltalk.

Multiple inheritance is one of the features that I find sorely missing from ObjC.

I don't disagree with this statement, but I don't think it's encyclopedic. It would be cool for someone to give a good pro/con discussion of multiple inheiritance over protocols/categories/delegation; did Smalltalk not have multiple inheiritance? It seems that protocols and delegation give you a way of avoiding it, keeping classes simple but instances complicated.

--Iluvcapra 01:20, 4 Dec 2004 (UTC)

3) I think GNU's implementation of GC deserves some expansion, as I believe they did it cleanly and in a very usable manner. IMHO, Apple would do well to simply copy it outright.

GNU did not implement GC with GCC. It uses the boehm-gc garbage collector AFAICR

Yes, but they added it. It's a GNU extension.

Re multiple inheritance, the way mixins are used in multiple-inheritance languages are precisely what categories are for, so I would agree with Iluvcapra's statement about protocols and other functionality giving you a way of avoiding it. Categories are so much more useful and obvious anyway ;)

Anyway, those are my 2c. Dysprosia 04:32, 4 Dec 2004 (UTC)

"Strong Typing"

The article mentions "strong typing" all the time where they in fact mean "static typing". All in favor of replacing? Wouter Lievens 12:44, 11 Mar 2005 (UTC)

Yes, of course. Dysprosia 00:02, 12 Mar 2005 (UTC)

Allright I'll do it Wouter Lievens 08:55, 22 Mar 2005 (UTC)

Misunderstanding in Language Analysis section

All Obj-C implementations have always had a runtime that did the message passing. The difference between the original Stepstone product, (and Stes's POC) and Apple's GCC extensions is that Stepstone implemented Obj-C as a preprocessor, while NeXT (later Apple), made a true Obj-C compiler; one that didn't generate C code as a stage in the compilation.

Only One Syntax Change

Objective-C is a very "thin" layer on top of C. In fact it includes only one syntax change and about a dozen new keywords.

Am I the only one who thinks that's totally inaccurate? Looking at the code snippets, it seems clear that there are quite a few very large syntax changes. -- Dpark 07:42, 2 May 2005 (UTC)[reply]

That's possibly true, but there really isn't all that much different from C. What's markedly different is the comparatively different way things are written in Objective-C than in straight C. The only syntax changes are the square brackets for method calls and the notation for method calls, the rest is merely keyword changes, eg "@interface", etc. I'll change that to two syntax changes. Dysprosia 09:11, 2 May 2005 (UTC)[reply]

Well, adding new keywords necessarily requires syntax changes. The entire concept of objects is absent from C. And this kind of code is completely different from C style code:

- (int)changeColorWithRed:(int) r green: (int) g blue: (int) b
...
[myColor changeColorWithRed:5 green:5 blue:5];

None of the code snippets in this article really look like C to me at all. I don't want to just remove the info, but I'd like to revise it so it makes sense to people who are familiar with C but not Objective-C. But without understanding what the "single" syntax change (or "two" syntax changes) is, I don't know how to fix it. -- Dpark 18:24, 2 May 2005 (UTC)[reply]

Those are the only two syntax changes I mentioned and changed. Other than the other keywords, it's all compatible with C. Have a look at the "Observer.m" file in the article. If you don't rely on OPENSTEP-style memory management, you use C-style memory management. The for loops, pointers, etc., it's all C.

None of the following lines (except the "else") or several others in the code are C syntax:

@implementation Observer

- (retval_t) forward: (SEL) sel : (arglist_t) args

  id <Notifiable> *ptr;

     if([element respondsTo:sel] )
        [element performv: sel : args];
     else
        [element error:"Unrecognized message sent via Observer"];

@end

Interpretting all of that requires significant syntax changes from C. I'm not saying that Objective-C isn't a strict superset of C. But it seems that it has a significant number of additions to the syntax. -- Dpark 03:46, 3 May 2005 (UTC)[reply]

I would point out that this sample is

@implementation Observer

New keyword line, defines a "namespace" (a class)

- (retval_t) forward: (SEL) sel : (arglist_t) args

Functionally, the same as

(retval_t) forward(SEL sel, arglist_t args)

namely, a function/method definition.

  id <Notifiable> *ptr;

Just another pointer declaration to some type.

     if([element respondsTo:sel] )
        [element performv: sel : args];
     else
        [element error:"Unrecognized message sent via Observer"];

Standard C syntax --

     if( boolean test )
        statement ;
     else
        statement ;

@end

ending keyword.

Maybe what's needed is the explicit mention that the two new syntaxes are:

1. Method declaration lines,

2. "[target operands]" is an rvalue expression.

--Keybounce 19:50, 16 May 2006 (UTC)[reply]

Don't forget that while C has no real concept of a dedicated object, this doesn't mean that there is a syntax change. A Objective-C object can be "casted down" to a struct, but it's not very common and isn't such a great idea in writing code. Dysprosia 03:15, 3 May 2005 (UTC)[reply]

I'm talking about the syntax used for declaring interfaces, declaring implementations, messaging, etc. It's all new syntax. -- Dpark 03:46, 3 May 2005 (UTC)[reply]

I've removed the line for now at least. If someone can explain what it was trying to convey, I'll try to rewrite it in a way that makes more sense, but this article is being cited elsewhere, and it's simply not correct. New language features require new syntax, and Objective-C has several language features not found in C. -- Dpark 03:58, 3 May 2005 (UTC)[reply]

Looking at the history, this:

Objective-C's syntax is based on Smalltalk, and is is different from that of C or C++

was suddenly changed to this:

Objective-C is a very "thin" layer on top of C. In fact it includes only one syntax change and about a dozen new keywords. The syntax change is for calling methods on objects, and is based on Smalltalk as opposed to C++.

That's a rather different message. I'm going to edit the section to say that Objective-C has a syntax borrowing from both C and Smalltalk. -- Dpark 04:13, 3 May 2005 (UTC)[reply]

Declaring interface/implementation is not really new syntax. It's merely using the new ways of writing methods and the new keywords in a certain block. That doesn't make it a new syntax altogether. Dysprosia 04:31, 3 May 2005 (UTC)[reply]

The syntax of a language defines what is legal. Interface/implementation declarations have a syntax. All language features have a syntax. -- Dpark 04:52, 3 May 2005 (UTC)[reply]

Ok, I think I see what you mean here. Dysprosia 05:04, 3 May 2005 (UTC)[reply]

Object to the use of this phrase (no pun intended, but hey... )

"Since Java was influenced by Objective-C, this is also the case in Java."

Even if there is evidence for this causal link, the sentence should be rewritten to one indicating that .. "The design of Objective-C contributed to the choice of single inheritance over multiple inheritence for Java."

i.e. contributed rather than caused.

You can fix this yourself, you know. By the way, see the Java article's external links for a document for evidence, if you're interested. Dysprosia 30 June 2005 02:44 (UTC)

GCC and `#import`

I was trying to find some information on why GCC insists on complaining about #import; and as always, a Wikipedia article was one of the top links. (This one, obviously.) I think it would be good to add something on that in the article.

However, I'm not sure exactly what. Here's a snippet from the comp.lang.objective-c newsgroup FAQ:

3.4 Why am I lectured about using #import ?

The GNU Objective-C compiler emits a warning when you use #import because some people find using #import poor style. You can turn off the warning by using the -Wno-import option, you could modify the compiler source code and set the variable warn_import (in the file cccp.c) or you could convert your code to use pairs of #ifndef and #endif, as shown above, which makes your code work with all compilers.

But the GNUstep user FAQ says the following:

1.2.4 What are these import warnings?

Do you get this obnoxious warning whenever you compile an application, tool, or Objective-C program:

warning: using `#import' is not recommended

[...]

Up until gcc 3.4, the #import directive was not implemented correctly. As a result, the GCC compiler automatically emitted a warning whenever #import was used. As of gcc 3.4, this problem has been fixed, so presumably, this warning is no longer emitted when code is compiled. If you are using an early compiler, you can supress these warnings by adding -Wno-import to your include (cpp) flags.

And leaving semi-official sources, there's all sorts of explanations, mostly "political reasons". So, style, politics, bad implementation, or something else? Does anyone here know? -- magetoo 17:07, 3 December 2005 (UTC)[reply]

There is absolutely nothing wrong with using #import, as long as it works properly. The reason I recall that the compiler spat out before was that declaration that the header should be included once should be made in the header, not in the code, but using #ifndef guards has never been traditional Objective-C style. Dysprosia 02:46, 7 January 2006 (UTC)[reply]

Exception catching

I am not sure, but is there 'try ... except'-like construction in Objective-C?

Yes, in the Apple extensions to Obj-C, but not in the GNU implementation. Dysprosia 02:46, 7 January 2006 (UTC)[reply]

In GNU since GCC 3.3. My book mentions only old Cocoa NS_ macros. --Pdemb 11:51, 8 January 2006 (UTC)[reply]

That doesn't mean you can use them. If you actually read the gcc manpage: "Currently, this option[-fobjc-exceptions] is only available in conjunction with the NeXT runtime on Mac OS X 10.3 and later." Dysprosia 12:17, 8 January 2006 (UTC)[reply]

Class Clusters

Completely missing from this article is any discussion of class clusters.

Class clusters is wrapping a large number of classes into a single public class. As an example, all the various number types -- short, int, long, float, double, etc -- have wrapper class -- NSShort, NSLong, etc --, and a grandparent wrapper NSNumber.

When you create an NSNumber, you automatically get an appropriate subclass.

This setup is extendable -- you could, for example, add a complex number type underneath NSNumber.

Class clusters requires categories, at least if they are extendable -- for the complex, for example, you need to be able to add something to NSNumber that can return your new complex class.

I don't know if Java 1.5 added anything to support this, but this type of construct was impossible in Java 1.4 and earlier, because of that need for categories.

As for basic types "Not full class citizens", years ago there was a preprocessor for statements like:

result @= a @* b @+ c;

that would turn it into math calls on those variables (assuming they were NSNumbers, or another class with similar methods.) This basically meant that an NSNumber wrapper was a full citizen.

Another example of a class cluster might be a wrapper on a read-only file -- depending on the file, it might be implemented as a memory mapped file, or a standard file that was seek'd around in. --Keybounce 19:41, 16 May 2006 (UTC)[reply]

The 'Messages' section is a good place to mention class clusters. It is because of the dynamicism mentioned in this section that class clusters work.

Biased and unsupported statement

I have just removed the following biased and unsupported statement from the article:

For these reasons, C++ has been popular for big, in-house, corporate projects, written by teams of average-proficiency developers, who must be treated as interchangeable resources. ObjC is more popular as a language for development of commercial or independent applications, by one or a few, high-proficiency developers.

This strikes me as POV-pushing at its worst. Unless someone can produce citable references that C++ is popular with "teams of average-proficiency developers", while ObjC is "more popular" with "high-proficiency developers" (I'd love to hear how the proficiency level of the developers in question was measured), then I think this statement is better left out of the article. --Allan McInnes (talk) 22:11, 25 May 2006 (UTC)[reply]

Comment by DarelRex: I do not object to Allan's removal of this statement from the section I added -- that seems reasonable and fair. For the record, by "high-proficiency developer" I meant a developer who can write large projects in straight C without creating a buggy, poorly organized nightmare. Most developers employed by large corporations for in-house apps need the restrictions of object-orientation (e.g. C++) to prevent that from happening. (Today it would be Java, which is even more restrictive.) That said, my section does seem much more professional and objective with the statement removed. Thanks, Allan. --DarelRex 17:42, 26 May 2006 (UTC)[reply]

You may well be right about the quality of in-house developers. My point was that unless someone can produce a reference that shows that

C++ is more popular for big in-house corporate projects than ObjC
ObjC is more popular than C++ for commercial or independent apps
In-house programmers are "average-proficiency" (by some measure) while commercial/independent programmers are "high-proficiency"

then your claims, while they may be well-grounded in reality, are not verifiable.

Another alternative would be to find an article where someone makes the same claims that you have, at which point it would be reasonable to add a statement to the effect that Person X claims that C++ has been popular for big, in-house, corporate projects, written by teams of average-proficiency developers... — this makes the claims a verifiable statement of someone's opinion. --Allan McInnes (talk) 18:39, 26 May 2006 (UTC)[reply]

Comparision to C++

"In C++, object-oriented is a coding style intended to force a certain kind of organizational structure on the sourcecode. The use of straight C in a C++ project is discouraged, and not all C syntax is even supported by the compiler. The C++ syntax looks very similar to C, but this is not considered confusing, because the developer is expected to "unlearn" C and do everything in the new, C++, object-oriented way. C++ comes with a large class library of very general-purpose classes, which is treated as part of the language; developers are expected to know it, use it, and subclass it.

In a C++ compiled executable, the method names are gone, and the machine code is not significantly different than that generated by a C compiler. Further, the objects are not truly independent entities, but rather temporary constructs of the object that created them."

I really don't understand the last sentence.

"C++ comes with a large class library of very general-purpose classes" - I thought it comes with a library of template classes, and programmers aren't encouraged to subclass them, but to instantiate them. I rather think of C++ as a tool for _generic_ programming, more than one for OO.

Indeed. This section was clearly written by someone who doesn't know C++ at all (I don't think there is a single class in the standard library that programmers are meant to inherit from, for instance). I've just removed the section, because I don't have anything useful to say about the topic, and that's better than just leaving bogus information sitting there. 71.68.75.61 07:17, 2 June 2006 (UTC)[reply]

I have added this section back in after it was entirely removed by the above, anonymous user. I have, however, made changes to it in response to the specific points of criticism that were offered in the above text. --DarelRex 13:54, 6 June 2006 (UTC)[reply]

I've rewritten the section entirely to conform to what C++ is actually like. I was hesitant to do this before and removed the entire section because I don't really know Objective C. 71.68.75.61 12:31, 9 June 2006 (UTC)[reply]

I think the rewrite is okay, but there was some good information about Objective-C that was removed from the section. Now it has a pretty heavy C++ focus, which might not be the best approach in an Objective-C article. – Mipadi 12:37, 9 June 2006 (UTC)[reply]

Thanks, Mipadi, for your wording edit. Looks good! --DarelRex 12:50, 7 June 2006 (UTC)[reply]

Glad I could help. :) – Mipadi 15:54, 7 June 2006 (UTC)[reply]

Obj-C vs. Obj-C libraries

Unlike C, Objective C does not specify any class libraries.

The root class Object and the metaclass Class are defined and the runtime provides for them, but semi-automated garbage control methods like retain and release are implemented by NSObject and not by Object. These methods were introduced with OpenStep (in NeXTStep we had alloc and free, remember?). Similarly with archiving, etc. I don't have any more time for this article tonight, but it needs some attention in this matter. It is possible that some of that information should move over to OpenStep instead...

Another thing that needs doing is dealing with the language specification. Things like formal protocols maybe should move toward the end, while really powerful and distinguishing features like Categories and poseAs: should be featured. Anyway, the article is a great start, but a bit of tightening would really make it shine. -- cmh 01:49, 2 June 2006 (UTC)[reply]

Archiving is possible in bog-standard ObjC. Object provides for read: and write:. I don't think your changes are entirely correct re typing either: specifically, "All 3 statements are equivalent at runtime", but I can't think about this for too long at the moment, so I'll get back to this properly at some other time. Dysprosia 04:56, 2 June 2006 (UTC)[reply]

Fair enough on the archiving... I'd forgotten about read/write. Note, though, that archiving as a technical usage generally refers to the NSArchiver mechanism. Perhaps calling it serialization would be better? As for the runtime equivalence issue, go ahead and try it... The compiler doesn't put typechecking into the code. All object typing is advisory to the compiler only. -- cmh 14:30, 2 June 2006 (UTC)[reply]

POV

I marked the Dynamic Typing section with a NPOV marker because of the last paragraph in the section. The words "sadly" "annoying" and just one too many uses of the second person make it lose its neutral point of view. Matthew Stuckwisch 04:36, 28 June 2006 (UTC)[reply]

I think you're missing the point: "sadly" doesn't imply POV, it means that a factual problem is being illustrated, that casting does break the discipline of static typing and this is not a Good Thing. The sentence should probably be worded for stylistic reasons, though. Dysprosia 04:58, 28 June 2006 (UTC)[reply]

In an article about a movie, you wouldn't write "Sadly, a sequel was never finished, which was an annoyance because the first one didn't fully explain to you what happened and you were left wondering why X did Y", it would simply say "Though the film ended without fully explaining the reasons for X's doing Y, a sequel was never finished, leaving it forever unexplained". Perhaps it is more a stylistic issue, but since I've seen people in the past expound both static and dynamic typing as A Good Thing™ in X language, it seemed a biased POV to me.

Your analogy is incorrect, and it's not about static and dynamic typing, the sentence is about casting. But we both agree the sentence needs to be rewritten, so there's no need to argue this further. Dysprosia 07:04, 28 June 2006 (UTC)[reply]

Claims in analysis section

I edited the paragraph "Categories and protocols may be used to provide many of the benefits of multiple inheritance, without many of the disadvantages, such as extra runtime overhead and binary incompatibilities." by removing the vague (POV?) claims about "the many disadvantages of mutiple inheritance". Mikademus 08:35, 7 July 2006 (UTC)[reply]

GC and OC

As far as I know, apple has not announced GC. While it may have been brought up at WWDC, with whatever betas, these are under NDA and so this fact is not verifiable from reliable sources. Thus I have attached the fact template. We should not be in a rush to include this fact in Wikipedia, there will be time enough to do so after it is released. Likely, if no reliable source can be found, this information should go for now. -- cmh 04:30, 15 August 2006 (UTC)[reply]

Garbage collection has been publically announced on the Apple web site as part of the feature set for Objective-C 2.0. ("Enjoy modern garbage collection, syntax enhancements, runtime performance improvements, and 64-bit support." [1])

Good enough for me. Thanks. -- cmh 19:42, 19 August 2006 (UTC)[reply]

Overloading clarification

Function or method overloading in the same class (a la C++) is not possible, as is shown in the following code:

@interface test
{
}
- (id)init:(int)i;     // line 4
- (id)init:(double)x;  // line 5
@end

@implementation test
- (id)init:(int)i
{                      // line 10
}
- (id)init:(double)x
{                      // line 13
}
@end

gcc 4.0.1 (from latest Apple development tools) gives the following errors:

test-overloading.m:5: error: duplicate declaration of method '-init:'
test-overloading.m:13: error: conflicting types for '-[test init:]'
test-overloading.m:10: error: previous definition of '-[test init:]' was here
test-overloading.m: In function '-[test init:]':
test-overloading.m:13: warning: conflicting types for '-(id)init:(double)x'
test-overloading.m:4: warning: previous declaration of '-(id)init:(int)i'

Engelec 19:59, 29 August 2006 (UTC)[reply]

I can verify this. The comon idiom is to write code like so:

@interface test
{
}
- (id)initWithInt:(int)i;     // line 4
- (id)initWithDouble:(double)x;  // line 5
@end

The logic with this design is that it is very clear what is intended and it prevents errors caused by type mismatches. One could argue that this route leads to needlessly verbose code. In practice this isn't a problem. From what I can tell this hasn't been added to the language because it simply isn't needed.

I'm sure there's still the possibility of function overloading in other cases, but I haven't been able to test anything. I could be wrong, however. Dysprosia 08:03, 16 October 2006 (UTC)[reply]

Infobox

Could someone who knows ObjC well enough provide a "programming language" infobox?

Could someone who knows wikipedia well enough direct me on how to do this?

Dynamic Typing

I object to the sample code provided on the grounds of correctness.

- setMyValue: (id <aProtocol>) foo;
- setMyValue: (NSNumber*)foo;

This is incorrect because these two lines can't exist together like this in the same header file. error: duplicate declaration of method '-setMyValue:'

This is bad style because the ObjC way to set values is to use the name of the value. It is best to give a concrete examples of this.

- setDelegate: (id <aProtocol>) anObject;
- setCount: (NSNumber*)count;

Forwarding

The sample code in the forwarding section is out of date for both MacOS X and GNUstep.

Instead, create a sample derived from the one <a href=http://www.gnustep.org/resources/ObjCFun.html>here</a>

- (void) forwardInvocation: (NSInvocation*)anInvocation
{
  if ([anObject respondsToSelector: [anInvocation selector]])
    return [anInvocation invokeWithTarget: anObject];
  else
    return [self doesNotRecognizeSelector: [anInvocation selector]];
}