[KEL9000]

Does anyone have any info on the additions to Obj-C in xcode 2.4? Or were there is any documentation on it?

Thanks

[Chuckit]

The only "documentation" I've seen of Obj-C 2 is on Apple's Leopard preview:

So compelling, Apple wrote Xcode 3.0 itself using it. Enjoy modern garbage collection, syntax enhancements, runtime performance improvements, and 64-bit support. At your own pace, since it’s backwards compatible with existing Objective-C source. Write applications more quickly with fewer bugs using Objective-C in Xcode 3.0.

I don't believe it's supported outside of Leopard and Xcode 3, though.

[KEL9000]

i was just interested in the improvements that are included. stinks there is no documentation.

[Chuckit]

I'm betting there is documentation in the Leopard dev release, but it's not public. Few people have it now and they're mostly under NDA anyway, so the info has not been leaked yet. Give it a few weeks, I think.

[oni]

one thing i have read is automatic garbage collection! This may make me get into some obj-c cocoa programming (java dev here)

[norville]

Originally Posted by KEL9000

Does anyone have any info on the additions to Obj-C in xcode 2.4? Or were there is any documentation on it?

Yeah, I'm guessing the Objective 2.0 spec is still under NDA. From what I've read, it's probably not even fully finalized yet. But there is some discussion of the "publically available" parts of it over on the Apple mailing lists... stuff culled from open source code, public announcements, etc. Quite interesting. I, too, am very much looking forward to this release!

[Chuckit]

I was hoping Obj-C 2 would implement a more Smalltalk-like "everything's an object" syntax and all that, personally.

[Millennium]

Originally Posted by Chuckit

I was hoping Obj-C 2 would implement a more Smalltalk-like "everything's an object" syntax and all that, personally.

That's not necessarily out of the question.

Frankly, though, Apple is being too tight-lipped about this, and tying Objective-C 2.0 to Leopard is just plain stupid. Apple should be trying to get these language features -or at least documentation for them- into the hands of developers as soon as possible, if it wants developers to be at all familiar with them before Leopard's release. Tying Objective-C's release to the release of another product, namely Leopard, is not a good way of doing that.

[Chuckit]

Originally Posted by Millennium

That's not necessarily out of the question.

Given what people have found out from the GCC source, it looks pretty definite that Apple is moving more in the Cocoa Bindings/Core Data direction of working common patterns into the language and tools than improving the syntax or semantics in any other way.

[Millennium]

Originally Posted by Chuckit

Given what people have found out from the GCC source, it looks pretty definite that Apple is moving more in the Cocoa Bindings/Core Data direction of working common patterns into the language and tools than improving the syntax or semantics in any other way.

True, but everything's-an-object presents a unique problem for Objective-C: it would stand a very real chance of breaking backward-compatibility with C. Apple relies very heavily on that compatibility, and so breaking it isn't something they can afford to do lightly.

As it currently stands, what is currently missing from Objective-C's object system? NSNumber covers most scalars, NSDictionary and NSArray (and their mutable versions) cover most sequences, NSString covers strings, and NSObject underlies them all. Am I right that functions-as-objects are the major missing piece of this puzzle?

[KEL9000]

to sum up the mailing list discussion: Garbage Control, Reflection, foreach, faster method calling and more are instore for Obj-C. It will be pretty sweet to have a native language that does stuff like this. I agree that Apple should be openly publishing documentation on this.

[WJMoore]

I imagine there will be plenty more documentation when it's released to the general public.

[Millennium]

Originally Posted by KEL9000

to sum up the mailing list discussion: Garbage Control, Reflection, foreach, faster method calling and more are instore for Obj-C.

Well, yeah, but that's actually surprisingly little information. What's the syntax: how can developers use it in their code? Does it track similar changes that GNUStep has been implementing (hopefully at least API-compatible), or does it go its own way?

[Chuckit]

From the mailing list:

- We have the syntax for properties, in both classes and protocols:
@interface MyClass : NSObject
@property int foo;
@property(getter=_getBaz,setter=_setBaz) float baz;
@end

@implementation MyClass
- (int)_getBaz { return baz; }
- (void)_setBaz: (float)newBaz { baz = abs(newBaz); }
@end

@protocol MyProtocol
@property(copies,readonly) NSString *bar;
@end

int main(void) {
MyClass *m = [MyClass new];
m.baz = -5.0;
printf("%f\n", m.baz); /* -> 5.0000 */
}

- Protocols can list required or optional methods:
@protocol MyProtocol
@optional
- (int)foo;
@required
- (void)bar: (int)arg;
@end


- The syntax for foreach is pretty obvious, but here it is anyhow:
NSArray *arr = randomListOfStrings();
for (NSString *s in arr) {
printf("%@\n", s);
}

It looks like there may be a facility for enumeration of user- defined types...

- To accomodate GC, fields can be weak:
@interface MyClass
{
__weak id some_var;
}
@end

[Maury Markowitz]

First up: can we put the interfaces in the .m files and ditch the .h? I mean, how 20th century...

- (void)_setBaz: (float)newBaz { baz = abs(newBaz); }

Nice!

for (NSString *s in arr) {

Nice!

m.baz = -5.0;

Very nice!

MyClass *m = [MyClass new];

Uhhh, not so nice. Or maybe it's just incomplete, can we:

MyClass *m = MyClass.new;

__weak id some_var;

*barf*

[Chuckit]

Originally Posted by Maury Markowitz

First up: can we put the interfaces in the .m files and ditch the .h? I mean, how 20th century...

That would be a bigger problem with C compatibility than allowing methods on primitives.

Originally Posted by Maury Markowitz

MyClass *m = [MyClass new];

Uhhh, not so nice.

I fail to see the problem.

[Catfish_Man]

Originally Posted by Maury Markowitz

First up: can we put the interfaces in the .m files and ditch the .h? I mean, how 20th century...

wtF? I would go INSANE without .h files.

for (NSString *s in arr) {

Nice!

m.baz = -5.0;

Very nice!

Agreed.

MyClass *m = [MyClass new];

Uhhh, not so nice. Or maybe it's just incomplete, can we:

MyClass *m = MyClass.new;

__weak id some_var;

*barf*

Let's not go overloading syntax too much. Apple is clearly making . for properties, not for methods. I'm of the opinion that having a language level distinction between the two concepts makes a good deal of sense (at least until methods become first class objects ).

[gperks]

Header files suck once you've tried a good IDE with say Java. Let the IDE show you the methods; who needs to edit two files? Why should I have to edit two files to create one method? Headers are so 1980s :-)

Going back to C++ from Java was, for me, a complete step back into the dark ages of programming. Header files and IDE weaknesses were a large part of that.

Is there anything like Eclipse's refactoring as a plugin for Xcode? Anything like their Quick Fixes? Xcode offers some syntax completion but that's all I've found so far. How about a simple "add method" and it adds to the .h & the .m for me, instead of me adding to one file and manually having to copy/paste to the other?

Anything like Intellij's Resharper (a C# refactoring IDE plugin)?

Refactoring, code-completion, and Quick Fix *massively* helps productivity, and it seems the C++/Obj-C world is really missing out.

[KEL9000]

I think organize imports is up there with refactoring and code completion in Eclipse.

[Gametes]

Yeah tell me about it. Isn't the whole cocoa philosophy to make automatic all the things programmers use over and over again, so we can stop reinventing the wheel and focus on "the things that make our programs unique" or something to that effect? Because if that's the case, why I have to worry about missing brackets, semicolons, etc is beyond me. The actual, physical structure of the header files and the implementation should be totally hidden, presenting me only with the unique aspects of my code.

Anybody used Quartz Composer? It's in the Developer apps folder, and man, if only XCode took a few hints programming would be like more like architecture and less like robotic poetry.

[Chuckit]

Checked out CoreData and Cocoa Bindings? They're pretty close to the Quartz Composer-like techniques it sounds like you're describing.

[KEL9000]

maybe they included some features in xcode3. isn't there a new interface builder also?

[gperks]

CoreData and Bindings are great - really good. CoreData & its IB integration has saved me hours and hours. Apple is doing a really great job at this level letting me get on with my application's value-add. Core Animation sounds like more goodness in this regard.

However, when you get to working on that level - your not UI-related application logic - Xcode doesn't offer much for that raw coding.

QuickFixes: Eclipse figures I am missing a semicolon. It'll add it for me at a keystroke. I'm not catching an exception - it'll add the code to catch it. I'm calling a method that doesn't exist? It'll create the method, correctly typed arguments, comment boilerplate and all. I forgot to declare a variable? It can add the declaration without me having to jump to the top of the method and them get back into the flow where I was typing. Once you actually come to compile in Eclipse, the chances of a compile error are very low. It assists you every step of the way.

The refactoring lets you chop and change your class hierarchy at will, pull methods up to superclasses, move this method to this other class, create an interface (protocol) from these methods, ... . Rename-anything will let you globally rename a class or method and have all references to it be updated.

I wish Xcode offered something similar for Objective-C.

[Thinine]

Except many of those features are impossible (or quite difficult) for Objective-C, due to the large amount of dynamism inherent in it.

[Chuckit]

Smalltalk was more dynamic than Objective-C and had similar abilities, if I recall.

[gperks]

Thinine, Obj-C is dynamic: however I don't think asking Xcode to offer suggestions to QuickFix common compile errors is impossible with Obj C. Forgetting to nest a []; missing a semi-colon; misspelling a method invocation; forgetting to declare a variable: these are all things Xcode could offer fixes for - it's suggestions might not always be right, but 90% of the time they will save me time.