Talk:Objective-C

From Wikipedia, the free encyclopedia

Contents

[edit] 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 —The preceding unsigned comment was added by Minesweeper (talk • contribs) 22:24, October 18, 2003 (UTC)

[edit] 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)

[edit] 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. —The preceding unsigned comment was added by 64.81.64.115 (talk • contribs) 05:36, November 12, 2004 (UTC)

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)

[edit] 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.

—The preceding unsigned comment was added by 64.81.33.177 (talk • contribs) 07:14, November 14, 2004 (UTC)

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)

[edit] 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)

[edit] 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. —The preceding unsigned comment was added by Maury Markowitz (talk • contribs) 19:24, December 5, 2004 (UTC)
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)


[edit] "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)

[edit] 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. —The preceding unsigned comment was added by 67.161.42.199 (talk • contribs) 11:54, April 8, 2005 (UTC)

In all methods, parameters are defined with a colon followed by the expected parameter type in parentheses and the parameter name. In some cases it is useful to add descriptive text before each parameter, and in some cases it is unnecessary. When working with large projects it is often very useful to have long, descriptive method names that make it easier to determine how each parameter is used.

-(void) setRange:(int)start :(int)end;

-(void) importDocumentWithName:(NSString *)name withSpecifiedPreferences:(Preferences *)prefs beforePage:(int)insertPage;

I'm assuming that the second line in the code above is an example where optional "descriptive text" is shown. I'm assuming that the two examples of descriptive text are "withSpecifiedPreferences", and "beforePage". Is there any syntax mistakes in this code segment? It would seem to me that the descriptive text are not in their proper sections, separated by the colons. This seems a little confussing and seems like it needs to be corrected or have a quick explaination inserted that it is indeed correct because ... Richwalt (talk) 21:21, 12 March 2008 (UTC)

[edit] 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)

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

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

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)

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)

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)
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)
Ok, I think I see what you mean here. Dysprosia 05:04, 3 May 2005 (UTC)

[edit] 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. —The preceding unsigned comment was added by 203.109.157.73 (talk • contribs) 21:39, June 29, 2005 (UTC)

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)

[edit] 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)

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)

[edit] Exception catching

I am not sure, but is there 'try ... except'-like construction in Objective-C? —The preceding unsigned comment was added by Pdemb (talk • contribs) 21:08, January 6, 2006 (UTC)

Yes, in the Apple extensions to Obj-C, but not in the GNU implementation. Dysprosia 02:46, 7 January 2006 (UTC)
In GNU since GCC 3.3. My book mentions only old Cocoa NS_ macros. --Pdemb 11:51, 8 January 2006 (UTC)
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)

[edit] Categories

The article implies that Objective-C created method categories and runtime loading of categories, while both of these ideas came from Smalltalk. It seems that the idea in Smalltalk was to use this for documentation, not extension, as classes could also be categorized. However I don't know how method categories were actually used. —The preceding unsigned comment was added by 69.12.192.122 (talk • contribs) 15:36, April 10, 2006 (UTC)


Isn't there a clear link between these categories and the notion of a Mixin? —Preceding unsigned comment added by 83.241.184.66 (talk) 13:57, 5 November 2007 (UTC)

[edit] 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)

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. —The preceding unsigned comment was added by Harveyswik (talk • contribs) 08:24, October 16, 2006 (UTC)

[edit] 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)

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)

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
  1. C++ is more popular for big in-house corporate projects than ObjC
  2. ObjC is more popular than C++ for commercial or independent apps
  3. 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)

[edit] 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. —The preceding unsigned comment was added by 141.3.26.29 (talk • contribs) 07:57, May 31, 2006 (UTC)

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)
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)
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)
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)
Thanks, Mipadi, for your wording edit. Looks good! --DarelRex 12:50, 7 June 2006 (UTC)
Glad I could help. :) – Mipadi 15:54, 7 June 2006 (UTC)

[edit] 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)

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

[edit] 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)

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)
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. —The preceding unsigned comment was added by Guifa (talk • contribs) 05:23, June 28, 2006 (UTC)
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)

[edit] 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)

[edit] 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)

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]) —The preceding unsigned comment was added by Shunpiker (talk • contribs) 18:07, August 19, 2006 (UTC)
Good enough for me. Thanks. -- cmh 19:42, 19 August 2006 (UTC)

[edit] 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)


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. —The preceding unsigned comment was added by Harveyswik (talk • contribs) 07:46, October 16, 2006 (UTC)

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)

[edit] Infobox

Could someone who knows ObjC well enough provide a "programming language" infobox? —The preceding unsigned comment was added by 85.126.110.203 (talk • contribs) 15:07, September 23, 2006 (UTC)

Could someone who knows wikipedia well enough direct me on how to do this? —The preceding unsigned comment was added by Harveyswik (talk • contribs) 07:41, October 16, 2006 (UTC)

[edit] 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;

—The preceding unsigned comment was added by Harveyswik (talk • contribs) 08:14, October 16, 2006 (UTC)

In context, there are two seperate examples "In the first statement, the object must conform to the aProtocol protocol, and in the second, it must be a member of the NSNumber class." This doesn't imply that each statement is to be used together. Dysprosia 08:39, 16 October 2006 (UTC)

[edit] 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]];
}

—The preceding unsigned comment was added by Harveyswik (talk • contribs) 08:19, October 16, 2006 (UTC)

The article is not about OS X nor GNUstep, it's about Objective-C. Just because Cocoa/OPENSTEP provide different library functions to perform forwarding, doesn't mean that it's somehow a part of Objective-C. It isn't. Dysprosia 08:35, 16 October 2006 (UTC)
You're right, I was wrong. The sample code is not out of date, it's just irrelevant for most people trying to do forwarding in Objective-C.

There are probably on the order of 10 existing implementations using @selector(forward::), everyone else uses @selector(forwardInvocation:). It's certainly true that @selector(forwardInvocation:) is not part of the language but it's also true that forwarding messages in Objective-C is done with the API provided by the base-class, not the language defined API. This should at least be mentioned.

Also, the comments are wrong in this code from the Forwaring section:

- (retval_t) forward: (SEL) sel : (arglist_t) args; // with GCC
- (id) forward: (SEL) sel : (marg_list) args; // with NeXT/Apple systems

Both examples work with GCC, just with different runtimes. The first works with the GNUstep runtime, the second with Apple Computers private runtime. In fact, I don't know of any other compiler or any other runtimes than those I just mentioned. Note that in the case of Apple this has nothing to do with Cocoa other than that the frameworks depends on the private runtime.

However, this information is really only usefull to those implementing a base-level framework(GNUstep, Cocoa, etc.) or a HOM implementation (most of those I've found use the NSProxy API). It's of little interest to anyone writing Objective-C code based on one of these base-level frameworks or using a HOM implementation because it's too low-level. —The preceding unsigned comment was added by Harveyswik (talk • contribs) 20:40, October 16, 2006 (UTC)

[edit] .m vs. .mm

I find it really strange that the article makes absolutely no mention of the difference between using the .m and .mm extensions for your implementation files. From [2], Apple’s Objective-C compiler allows you to freely mix C++ and Objective-C code in the same source file. This Objective-C/C++ language hybrid is called Objective-C++. With it you can make use of existing C++ libraries from your Objective-C applications. Note that XCode requires that file names have a “.mm” extension for the Objective-C++ extensions to be enabled by the compiler. —lensovet–talk – 02:16, 25 January 2007 (UTC)

[edit] Dot notation

I was under the impression that the dot notation could only be used to access properties, and not for all method calls. Ddfreyne 13:05, 27 May 2007 (UTC)

Correct; however, I believe that it will be available for all method calls (like Java) in Obj-C 2.0 —lensovet–talk – 18:59, 27 May 2007 (UTC)

I've been tracking Objective C 2.0 for months, and nothing that I have seen, including GNU GCC repository code updates from Apple, indicates that dot notation will be available for anything but properties. In fact, doing dot notation for methods would be a major change and causes all sorts of problems like how to handle methods with more than one parameter. So I'm going to try out Wikipedia's famous editing abilities and use my authorative knowledge of Objective C 2.0 to correct the article by deleting this section. - steve

[edit] Rephrasing of garbage collection section

The previous version of the garbage collection section made it sound like "garbage collection" and "reference counting" where equivalent terms, which they are not. I rephrased it to remove this implication, but in the process also removed the mention of reference counting.

If the intent was originally to communicate that the garbage collection implemented for 2.0 used reference counting, please someone rectify this or let me know where I can read about it. I did not find a lot of concrete information when I attempted to Google around, and I am not personally aware of the details.

--Scode 11:28, 12 August 2007 (UTC)

[edit] Analysis of the language

"As of 2007, all Mac OS X classes and functions in the Cocoa programming environment are prefixed with "NS" ..."

This isn't quite right. What about CoreFoundation? Perhaps we should distinguish the "higher level" parts of the Cocoa frameworks from "the Cocoa programming environment" when making such a statement. It would also be prudent to distinguish, say, the AddressBook and CalendarStore frameworks from "the Cocoa programming environment" since they also don't use an "NS" prefix (but "AB" and "Cal" respectively). —Preceding unsigned comment added by 128.231.88.5 (talk) 20:03, 25 February 2008 (UTC)

[edit] User Manual Not A Article

This article is a bit ridiculous. First it is too long. Second it is too technical. It's really not an article at all. It is actually the start of a user manual. —Preceding unsigned comment added by 75.210.51.228 (talk) 14:57, 12 April 2008 (UTC)

[edit] Protocols v. Java Interfaces

From the section on protocols:

The Objective-C concept of protocols is different from the Java or C# concept of interfaces in that a class may implement a protocol without being declared to implement that protocol. The difference is not detectable from outside code.

I can't speak to C#, but I don't think this is accurate in the case of Java. Just as you can implement a protocol in an Objective C class without declaring the protocol, you can implement an interface in a Java class without declaring the implementation. This approach might be less useful in Java due to the greater use of static typing, but it certainly can be done.

I'm not sure what is meant by the difference (presumably between a declared protocol and an implemented but undeclared protocol) not being "detectable from outside code". It's my impression that a class which implements a protocol but does not declare the protocol will not return true for a conformsTo protocol test. Perhaps this is what is meant by detecting the difference "from inside code". What could be meant by detecting the difference "from outside code"?