Sony Adopts Objective-C and GNUstep Frameworks 345
EMB Numbers writes "Sony has revealed that the new SNAP development environment for 'consumer electronics' is based on Objective-C and the open source GNUstep implementation of Apple's Openstep spec. While Apple has continued to update their specification in the form of Cocoa and Mac OS X, GNUstep has preserved the original standard. Anyone familiar with Cocoa Touch and iOS will feel right at home developing for Sony. There may even be some source code compatibility between the platforms. The world continues to chase apple — probably for the better."
Re:How compatitble (Score:5, Informative)
Summary is incorrect (Score:5, Informative)
Please read the definition [gnustep.org]
Re:For the better? (Score:5, Informative)
Re:For the better? (Score:2, Informative)
Re:For the better? (Score:5, Informative)
Also doesn't it's dynamic runtime stuff allow certain things that C++ doesn't?
Yeah, like built-in introspection [wikipedia.org] and reflextion [wikipedia.org]. Stuff like RPC (remote procedure calls) [wikipedia.org] is simple and flexible under Objective-C but under C++ it has to be hard-coded in and can be very brittle.
Re:C/C++/Objective-C OOP (Score:2, Informative)
Why not learn something decent instead, like Ruby or Python?
Re:Summary is incorrect (Score:3, Informative)
Apple has always been one of the driving forces behind Unicode.
For selected values of "always". Apple has supported Unicode well since OS X, that is since 2001 or so, or in other words, ten years after the Unicode standard was published. Even Windows was earlier - Unicode support in Windows NT 3.x was there on the API level, in NT 4 it would work well if your programmers had been halfway diligent, and in Windows 2000 it would work well out of the box. With Apple systems before 2001, it was a pain to get Unicode working properly on MacOS 9 - it was technically supported in 9.x, but it didn't really work all that well.
With OS X, Apple finally had the opportunity (that Plan 9 had had something like a decade earlier) to design a new API that used Unicode for all strings. Prior to OS X, the Apple device that supported Unicode best was the Newton, and even there you didn't have proper input methods and rather limited font support.
Re:For the better? (Score:4, Informative)
Nice link on Reflection, every now and then I wish I could do that but didn't know I could.
There's a lot more to it if you dig deeper:
Objective-C Runtime Programming Guide [apple.com]
You can do some pretty neat stuff like dynamically creating a class and adding methods to it. Some of it should only be used as a last resort but it's nice having the tools at hand if you really need them. This kind of stuff is either extremely difficult or outright impossible in C++.
Yes, there are some performance penalties to a dynamic runtime but for most cases it is negligible. If you desire you can circumvent the dynamic aspect of Objective-C and "freeze" method calls in order to get around those penalties for performance-critical code. There's a great series of articles on this subject: The Optimizing Objective C Series [mulle-kybernetik.com]
Comment removed (Score:4, Informative)
Re:Bizarre choice (Score:3, Informative)
Re:For the better? (Score:4, Informative)
You CAN do reflection in C++ as the code base for one game I saw ... the catch is you need a super-base object, templates, and macros to pull it all off ...
but yeah, there is no _native_ language support for it.
Re:For the better? (Score:4, Informative)
But I'll grant you any day that Obj-C could do with some modernisation, in particular w/r to namespaces.
In the end namespaces are very little more than appending more characters on a name. You can get most of what namespaces do just by adding a unique string to part of your class name. Yes, there is a possibility for clashes if someone chooses a string which is the same as yours but how often do people use outside classes other than the ones in the Cocoa frameworks?
At best there should be some sort of prefix directory where developers can register their class prefixes and make sure that they have a unique string. Apple already uses NS and CF so most developers know do avoid using them.
Here's some good reading on the topic:
Cocoa Style for Objective-C: Part I [cocoadevcentral.com]
ChooseYourOwnPrefix [cocoadev.com]
Re:Bizarre choice (Score:3, Informative)
If you're *starting* a new project, D might be an option, but the GGP's assertion was that Objective-C was a mistake that Apple made.
According to Wikipedia, D first appeared in 1999, long after Apple acquired NeXT and its Objective-C based OS which was the foundation for Mac OS X. iOS is based on OSX, so it follows that they'd re-use the core parts rather than re-write it from scratch and have to maintain two distinct OS programming skillsets, if a different language didn't provide substantial benefits over staying with Obj-C.
Huge disadvantage for system programming (Score:3, Informative)
Ada2005,Eiffel,Lisp (with CLOS for OO),OCaml
None of them can work with C code so directly as Objective-C, which is a very large advantage indeed for systems programming, and a decent advantage for other forms of programming too (like being able to use something like a blowfish library with almost no work).
Now that Objective-C has closures, I'm not sure I really see that great a benefit of any of those languages over the drawbacks.
If you like a LISP syntax, consider Nu [programming.nu] which is an S-exp based variant of Objective-C and call compatible so it maintains the same benefits.
Re:Apple's response? (Score:3, Informative)
Apple also owns the rights to Obj-C
???? Obj-C was created by Brad Cox in the early 80s. Next licensed the trademark from StepStone. GCC has had an objective C compiler in it (as described by Cox) since the early 90s. As it is, the compiler used by Apple is the GCC compiler with some extra features such as properties (which have been released as gpl and are available for download from apples website). With the exception of trademarks and patents on an implementation, you can't own a language. Anyone can build a compiler for the same language with a different name (with exception of patented parts of implementation which is less certain with Bilski).
Re:For the better? (Score:1, Informative)
Obj-C really looks like someone tossed a completely different language into C
It's Smalltalk.
Brad Cox's inspiration for writing Objective-C came from the 1982 issue of Byte magazine that covered Smalltalk.
--lowell
Re:Netscape (Score:1, Informative)
Yes, there is a possibility for clashes if someone chooses a string which is the same as yours
Does NS stand for NeXT Software, or does it stand for Netscape?
It refers to NeXTStep, from which OpenStep was derived.
Re:Netscape (Score:3, Informative)
Yes, there is a possibility for clashes if someone chooses a string which is the same as yours
Does NS stand for NeXT Software, or does it stand for Netscape?
Neither - it stands for NeXTSTEP
Re:How compatitble (Score:5, Informative)
What are you talking about? The example you call insightful is very readable.
It's the brackets and the "initWithThing:x otherThing:y" paradigm that I find unintuitive and difficult to read, most especially the "let's combine the method name with the name of its first parameter!" idea. Why did they throw out perfectly understandable function call syntax in favor of surrounding everything with brackets? I know they're trying to pretend they're sending "messages", but what they ended up with is virtually identical to the standard in C except in superficial syntax.
Why did they throw out C's perfectly readable struct-definition syntax in favor of this "@interface" and "@end" and "@property" nonsense?
Why do you have to manually derive all interfaces as children of NSObject? That would be like Java requiring you to explicitly derive every class from Object. You're never not going to want your class to be derived from NSObject, so it should be assumed.
Why do they use "+" and "-" for static methods vs instance methods? Did they really think "+" and "-" were more intuitively clear than, I don't know, using the 'static' keyword that was already in the language? Is it so absurd to want method specifiers that are actually clear in their meaning?
Why did they throw out perfectly understandable pass-by-value and pass-by-address parameter passing?
None of these changes from C are for the better.
I will say that #import is an improvement over #include; I wish something similar had been adopted in C++. Still, tiny improvements like this do not offset the idiocy with which the rest of Objective-C was designed.
I suspect you are more of a "get off my lawn" type who thinks things should be done the way you learned them and anything different is to be feared.
I have used languages with widely varying syntaxes and design philosophies (I enjoyed working with Scheme, for example). I don't "fear" different ways of doing things; I do have opinions about which ways of doing things are stupid. Having a negative opinion about a specific language you like does not automatically mean I'm just shaking my bony fist in the air and shouting "get off my lawn".
Let me make myself clearer: what bothers me most about Objective-C is that it tries to pretend it's like C even while doing everything it can to be different from C without being so different that it can't have the C in its name anymore, all while retaining several of C's disadvantages and gaining very few of the advantages it claims.
renew/release isn't very difficult to understand, but if you can't keep up, Objective-C has garbage collection.
No, it's not particularly difficult to understand, but that's not my point; Objective-C's garbage collection only collects objects whose reference counts are zero. That's the whole reason you have to properly handle your reference counting. In other words, Objective-C gives you all the downsides of being forced to manage memory, combined with all the downsides of garbage collection.
(I realize garbage collection has advantages; however, by forcing you to manually handle reference counting, Objective-C negates those benefits by design. In other words, all Objective-C gains you is that instead of freeing your memory at predictable times, the garbage collector will come along at unpredictable times and slow down whatever it is your program is doing.)
Objects != string pointers, and that's a problem for you? Seems like a fairly basic idea to grasp.
It's not that, it's that nothing in Objective-C even works with char*s, other than the one init method on NSString. Want to display a char* in your UI? Hope you don't mind converting it to NSString first!
Worse, by default, string constants in your code are char*s, not NSStrings! If you want your string constant to be an NSSt
Re:"The world continues to chase apple -- probably (Score:2, Informative)
Re:How compatitble (Score:3, Informative)
I agree with some of your points (and don't much like Obj-C as a language), but others are incorrect.
Why do you have to manually derive all interfaces as children of NSObject? That would be like Java requiring you to explicitly derive every class from Object. You're never not going to want your class to be derived from NSObject, so it should be assumed.
You're only going to derive from NSObject when you're writing for Cocoa; it's not a magic base root class that's inherent to the language like java.lang.Object is in Java. It is perfectly possible to use Obj-C with something other than Cocoa, and then you'd have your own root class different from NSObject.
more intuitively clear than, I don't know, using the 'static' keyword that was already in the language? Is it so absurd to want method specifiers that are actually clear in their meaning?
There's actually nothing particularly clear about the use of "static" modifier to mean class methods. That C++ made a mistake of doing that once in the past, also inventing the misnomer "static method" in the process, which has stuck since then, is a rather poor excuse. Back when Obj-C was designed, anyway, it was not anywhere as widespread as it is today.
I agree that the use of "+" and "-" rather than keywords is silly, though.
Why did they throw out perfectly understandable pass-by-value and pass-by-address parameter passing?
Huh? There's no such thing in C. All parameters are passed by value. Sure, you can pass an address of something (i.e. a pointer) by value. And hey, you can also do that in Obj-C!
Objective-C's garbage collection only collects objects whose reference counts are zero. That's the whole reason you have to properly handle your reference counting.
That is plainly not true. In fact, when you have tracing GC enabled in Objective-C, it doesn't even do reference counting on objects - any explicit "release" and "retain" messages will not even reach them. You do not need to "properly handle your reference counting" etc.
The only annoyance at the moment is that GC is not available on iOS.
It's not that, it's that nothing in Objective-C even works with char*s, other than the one init method on NSString. Want to display a char* in your UI? Hope you don't mind converting it to NSString first!
Not any different from std::string or QString, then.
At the very least, they should have made the language automatically convert char*s to NSStrings, and vice versa, where necessary!
Well, that's a bit tricky in practice.
Implicit conversion from NSString to char* is unsafe because you don't know how that char* would be used. What if someone tries to write to it as if it's a buffer? If you give them pointer to internal NSString storage directly, then you can end up with an object in an inconsistent state pretty easily. If you allocate new storage and copy it over, then 1) it's quite expensive for an implicit operation, and 2) who's going to free it, and how do they know they need to?
An implicit conversion from char* to NSString has the same problem of object ownership, but that is moot when GC is there.