Java vs Objective-C: The Smackdown
Andy on Nov 7th 2006
I’m in the process of translating an incomplete Java program I wrote into an Objective-C program. It’s a simple interpreter for a very simple kid programming language. At the time, it had been a while since I had dabbled in Java and thought it would be fun to get back into it. After all, it had “generics” and whatnot now, and other features that C++ programmers claimed it needed to be a “real” language. And what could be more fun than the overuse of angle brackets, incomprehensible error messages about type conflicts, and sounding all smart rambling on about “generics?”
Gooey Troubles
The Java programming went well until I had to start implementing the user interface for the interpreter. Now the language uses lots of graphics and such, because its supposed to be visual, and thus more fun for the kiddies. Although I remembered Java as being a nicely designed language, with a good runtime library, I had forgotten how bad the GUI programming was. Perhaps I was simply repressing the traumatic memories.
First off, there are a lot more choices for GUI programming in Java now than there was the last time I did Java programming. Back in the day, it was AWT (Abstract Window Kit) or nothing. AWT wasn’t horrible, assuming you were a masochist, but you couldn’t precisely position things, and the controls never looked native. Oh, and it was insanely slow too.
Fortunately, today you have more than one choice when it comes to UI toolkits. There’s still AWT, but Sun also introduced Swing (as in, swing from a rope) to replace AWT, and IBM came up with SWT, which apparently stands for “Swearing With Toolkits.” Now, when I say Sun replaced AWT with Swing, I actually mean they confused the hell out of me. Because Swing doesn’t actually replace AWT. It kinda supplements it in some places, while in others outright replaces AWT classes. But good luck figuring out which class does what. After about an hour with the Swing documentation I decided it’d be easier to just implement the entire UI in ASCII art. Oh, and if you were worried about the non-native control look in AWT, don’t worry, Sun kept that feature for Swing.
Then there’s SWT, which apparently stands for Surely the Wrong Thing. It was created by IBM for the Eclipse project, because AWT and Swing were so awful. But don’t worry, IBM bested Sun at its own game and managed to create something that was even worse. The Mac version of SWT was written by an Mac hating chipmunk. It uses old style Carbon controls and Quickdraw. That’s right, not even HIView’s and CoreGraphics, much less Cocoa. I’m hoping that since Adobe has an Eclipse plugin now, that they’ll rewrite SWT/Mac to be something decent, much like what they did with Premiere.
There’s also the Java Cocoa bindings from Apple. They’re not all that up-to-date though, and Apple has said they’re not going to be supported any more. Furthermore, if I’m going to be writing to Cocoa, why am I writing this program in Java?
So that’s where I stopped with the Java project. I decided that I didn’t really need all this pain to do, what should be, basic GUI programming.
Learning from the pain
I have a confession to make: I like Java. Or, more precisely, I want to like Java. I like the simple language design. It’s easy to read and write. It comes with a great runtime library: built-in threads and sockets and all sorts of good stuff. I think there’s a few things Objective-C can learn from Java, other than how to be tasty.
Probably the biggest thing I noticed when converting this Java program into Objective-C was the the garbage collection. What used to be a one line assignment in Java ended up being three or four lines in Objective-C to make sure it was retained and released properly. I found that there was more Objective-C code than Java code, primarily because I needed to manually manage memory. When I write straight Objective-C code, I don’t really think about it, because where I started, C++, memory management is even more manual. But doing the conversion really drove the point home: I’m wasting a lot of thought cycles and code on memory management. I also found that I suddenly had to worry about cyclic references, which I didn’t have to worry about in Java.
I know Objective-C 2.0 is going to have garbage collection, but it can’t get here soon enough for me. This conversion process only confirms the fact that the feature is well overdue, and how insufficient simple reference counting is.
Speaking of memory management, why is it that I have to manually call alloc and init? And inside my init, why do I have to manually call my super class and check self for nil? Why do I have to call my super class in dealloc? Maybe I’m delirious from all the reference counting I’ve been doing, but it seems to me like that’s all boilerplate code. Boilerplate that the compiler should be taking care of, not lazy ‘ol me.
Other than memory management, my other gripe is exceptions. Objective-C doesn’t unwind the stack per-se, it essentially just restores the stack and registers to a previous location, much like a thread context switch. i.e. It does a setjump() and longjump(). That means things get left dangling, memory leaks (’cause, you know, no garbage collection) and it’s generally harder to clean things up and get back to a known, stable state. I know exceptions still work this way because of historical reasons, but it has to move on at some point. Currently the exception handling is pretty much worthless, which is probably why Apple still recommends NSErrors instead of exceptions. Exceptions aren’t worthless, just the way Objective-C implements them is.
No, it really was that painful
Now, lest you think I’ve gone all soft on Java, I have plenty of other gripes about Java. These didn’t come rushing back until I started the conversion to Objective-C.
Enums. Seriously, Sun, what up with that? One of the easiest to understand programming concepts, that’s equally as easy to implement, and it’s completely not there. What, did you think I’d like to list out every constant value, along with it’s type and value, instead of the compiler inferring the type and automatically generating a value for me? I may be a masochist, but I’m not that much of a masochist.
I’m still trying to figure out mule-headed reasons behind the “no free functions” rule. Is the thought that it would force the users to write object-oriented code? As they should be well aware, you can write really bad non-objected oriented code using just classes. Just look at MFC. Furthermore, just because someone writes a free function, that doesn’t make the code not object oriented. This failure of the Java language just feels like a religious argument to me.
Java really strives to be easy to read and understand. This lead to the fact that object parameters are passed by reference, while scalars are always pass by value. While this is somewhat easy to understand (See kids, this arbitrary type is reference, while this other arbitrary type is value), it doesn’t help real programmers. Because sometimes, I just have the crazy urge to retrieve the results of a function that’s done some work for me. I had more than a few classes that were just wrappers around out parameters.
And don’t even get me started on that stupid exception specification checking. Morons.
Ending the pain
Comparing Java to Objective-C is interesting to me because Java was influenced by Objective-C. All in all, almost all constructs in Java have a direct equal in Objective-C, which makes the conversion process fairly straight forward. However, while Java has continued to evolve, Objective-C hasn’t. Well, Apple is pushing forward with Objective-C 2.0 improvements, but the language has been dormant for many years. Hopefully, Apple will continue the improvements, and Objective-C can catch up.
As for Java, they just need to scrap all their previous GUI attempts and start over again. Until then, I don’t care how much support for “generics” or other modern language features Sun adds, I can’t take it seriously as a language or a platform.
Filed in Macintosh, Programming | 35 responses so far
Romain Guy Nov 7th 2006 at 03:01 am 1
You will be glad to learn that real enums have been available in Java for more than 2 years.
As for the GUI toolkits you should try it again, more seriously maybe. You can achieve some really cool stuff with Swing. Sure, this toolkit has its own share of issues but it gives you a true cross-platform tool and a vast amount of flexibility.
I urge you to take a look at the following videos to get a better idea of what you can do with Swing: http://www.jroller.com/page/gfx?entry=aerith_hd_videos (granted, this app could be better integrated with Mac OS X but we were really short on dev time.)
Something else that’s very important for Java developers are the tools. Not only are the IDE incredibly powerful, compared to Xcode for instance, but you also get many frameworks and building blocks that can take you quite far as soon as you start the project (see the NetBeans Platform or the Eclipse RCP.)
Last but not least, your comment “And don’t even get me started on that stupid exception specification checking. Morons” is a bit scarce. I hate the overuse of checked exceptions but I don’t blame the language, I blame the @#! developers who abuse this feature. If you program in Swing you will rarely have to check for exceptions. They mostly “happen” with I/O code (where you probably want to catch them anyway.)
I am personally very very happy with Java, and very very happy with Objective-C/Cocoa that I’ve started learning recently. Both are useful, both can be used alongside (at least I can easily make Windows apps on my Mac
Nice article though!
Scott Stevenson Nov 7th 2006 at 03:41 am 2
It seems to me your only real complant with Objective-C is lack of garbage collection, and that’s coming in Leopard.
In fact, you actually seem to have more gripes about Java, and they’re far less likely to ever be addressed.
Scott Stevenson Nov 7th 2006 at 03:43 am 3
but you also get many frameworks and building blocks that can take you quite far as soon as you start the project
I think this applies just as much to Apple frameworks, or moreso — particularly if you’re writing desktop apps.
Romain Guy Nov 7th 2006 at 04:35 am 4
Scott: From what I’ve seen the Apple frameworks only address part of what RCPs can offer, but then I might overlook a lot. And the issues raised here against Java can be addressed, after all enums have been added to the language two years ago
Andy Nov 7th 2006 at 04:42 am 5
Hey Romain Guy,
My mistake on the enumerations. It’s good to see that they’ve finally added the feature. I guess that goes to show how long I’ve been out of the Java game.
As far as Swing goes, my biggest disappointment is the end results. Java has come a long way on the Mac, but it still doesn’t look native. Especially when Windows programmers write them.
And I fully admit the comment about about exception specifications was sensational, and probably over the top. However, while well intentioned, I find it to be one of the most annoying features of the language.
Thanks for the feedback.
Andy Nov 7th 2006 at 04:48 am 6
Hey Scott,
I will agree that garbage collection is my biggest gripe. However, I still think proper exception handling is important. Without proper stack unwinding, you can’t even consider rooting of locals, “resource acquisition is initialization,” and automatic cleanup when variables go out of scope.
As far as what might get addressed in Java, I don’t know. Sun is moving the language forward, although I’m not sure often they read my blog.
Thanks for the feedback.
Sanjay Samani Nov 7th 2006 at 06:55 am 7
Andy,
I haven’t used them extensively, but I thought that Objective-C’s @try-@catch-@finally blocks worked the same way as Java exceptions where you can do the clean up in the @finally section.
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/index.html?http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_4_section_9.html
There is also the Macro method using NS_DURING / NS_HANDLER / NS_ENDHANDLER that is not as robust. Is that what you’re referring to or is the guts of @try..@finally not as strong as Java?
Sanjay
Ulrich Hobelmann Nov 7th 2006 at 08:43 am 8
Hi Andy, I share your pain. GUI dev on a Mac isn’t all that rosy. I agree on most points against ObjC, and unfortunately it’s very much a niche language that’s only being used by one vendor (yes, Apple), which doesn’t really help a lot with the ecosystem surrounding it.
I’ve hated Java for a long time, but Java 5 is actually very usable. On the Mac Swing even looks halfway decent (no, not Cocoa-native, but certainly better than your average Carbon or X11 application), and some platforms (say, NetBeans RCP) have even improved on that.
I’m not sure what NetBeans does to get native menubars, because when I built it myself it didn’t really work (it had Swing-like menubars inside the window). They must have some kind of Swing patch I guess. But with that applied, compared to Eclipse/SWT NetBeans looks quite nice.
Yes, other than that Swing probably still isn’t too great, if you want to do more than write very basic Business UIs, but it’s getting better rapidly. On non-Mac platforms they say Java 6 is a huge improvement again (well, Swing looked pretty un-native on those platforms before), and I’m curious how it will end up on the Mac.
I really like native UIs, but I’m not sure that developing on the Mac really has a big productivity bonus. Right now I think it doesn’t. And Java is moving ahead with big momentum, including GUI work and rapid development tools (NetBeans is slowly approaching Interface Builder’s power, you could say).
Emil Nov 7th 2006 at 12:49 pm 9
I just need to add one of javas gripes for me.. (well is true for obj-c too)
Why cant you “const” declare a class method?
Yes, most the java platform is designed as immutable… but common,
why cant I know if a class internaö changes when I call a method.
How many times have you used a 3:rd party framework.. and really have to test to see the result.. (the doc might not be updated or non existing)
Regarding javas GUI alternatives.. I so much totally agree!! Its a shame really, why dont they use reflection? Then they could have made it so much more like Cocoa!
Regarding java generics… well in java they just represent a generic container… which is very limiting. No availability to do meta template program with thoose… so java is still missing out on that. Still I think you shouldnt press/include every feature in every language. Just use what is best for the task at hand.
This is why I really like the crosscompiler (so you can mix c++ and obj-c) in XCode. No doing a JNI c binding in java doesnt count.
Martin Nov 7th 2006 at 12:50 pm 10
Hi Andy,
maybe I did not fully understand your intentions, but for what it’s worth:
> Enums.
Ok, that exists, as we know now
It’s just more typesafe now. And certainly more typesafe than enums of C (which I’d known before - and never used 
It’s funny, but I never missed it: I used int constants. Then I ran into some guys that used confusing naming to increase the likelihood of me picking the wrong constant…
> I’m still trying to figure out mule-headed
> reasons behind the “no free functions” rule.
I think, Java has always had these: Static methods are just that. “Free functions”. Of course you call them
MyClass.myStatic();
rather than
myStatic();
but that class is just a name space to avoid clashes. Ok, it’s also the delivery unit since the code of the method ends up in that .class file, but that’s ok with me: If I don’t want to associate some functionality with instances of one type I place the statics in a utility class that cannot be instantiated but just acts as the “sourcefile” where my methods are (also in C, C++ and Objective C I will have to pick a “source file” for my “free functions”).
Finally, if you really want to write
myStatic();
without the need to repeat the prefix over and over, you use a static import. That one exists exactly as long as the enumerations, i.e. since Java 5.0.
Passing by reference:
>… it doesn’t help real programmers.
> Because sometimes, I just have the crazy
> urge to retrieve the results of a function
> that’s done some work for me. I had more than
> a few classes that were just wrappers around
> out parameters.
Why, I thought “real programmers” can help themselves
I found that, with functional languages, closures are often used for exactly that. And they seem more natural and more elegant than reference parameters. Although, like enums, I haven’t missed them, I begin to think that they would be a bonus to the Java language. And I believe that there’s a real chance they will be supported in future; at least the restriction for local inner classes that they can only access finals in their local context isn’t all that unlikely to be removed some day. Plus there’s still hope for closures.
Ok, seriously, I think that what you really want here is support for closures. Over the years of wondering what people particularly liked about their favourite language (when bashing others
> And don’t even get me started on that stupid
> exception specification checking. Morons.
I guess, the last word refers to people abusing checked exceptions. After my “initiation phase”, I found I’m defining checked exceptions less often. I reserve them for the occasions where I really want to get a design point across. The feature is ok, just when overused (and misused, probably in connection with excessive exception wrapping and rethrowing
it seems a bad idea - not the feature, just the abuse. my 2c.
Martin Nov 7th 2006 at 12:57 pm 11
Hi Emil,
as for
> Regarding java generics… well in java they just
> represent a generic container…
> which is very limiting.
I think, they can be used for more than just generic container classes. The fact is just not very well known yet. No problem if someone did not want more: he’ll happily use it for containers.
Romain Guy Nov 7th 2006 at 01:24 pm 12
Emil,
You can actually “const” the parameters. Well, sort of
The keyword for that is called final. It won’t prevent the code from modifying the content of your object but it will at least not be able to change the reference.
Ulrich,
If you can, take a look at Java 6. It is indeed a great improvement and it’s much much faster than Java 5 which was already really cool on that side. Now I have to admit that Apple’s VM implementation is not the best one around, especially when it comes to advanced graphical stuff which easily break it.
To get a real Mac OS X menu bar, or a good Dock name, or a good fullscreen behavior, etc. you can simply use command line flags (that you can also put in the plist used to launch Java apps on Mac OS X.) Your application can even set those properties at startup time, form the code. For instance, to use the system’s menu bar, add -Dcom.apple.macos.useScreenMenuBar=true to the command line or to Info.plist. It’s just a shame that most developers don’t bother making their app work seamlessly on Mac OS X (I know that because I was culprit of that not so long ago
Andy,
Sun might not be reading your blog (that said, I’ve forwarded them your blog entry
but Java has one great benefit. The JCP (Java Community Process) lets the community members request changes and give feedback to proposed changes. For instance, the additions of the generics, of the for-each loop or of the enums come from one JCP specification request.
Anyway, I can’t wait to get my hands on Objective-C 2.0 and a brand new shiny garbage collector
Emil Nov 7th 2006 at 01:26 pm 13
Hi Martin,
as for
” I think, they can be used for more than just generic container classes. The fact is just not very well known yet. ”
I not so sure about that.. but I would love you to prove me wrong!
What I know you cant do neither template specializatior or use primitive
parameters as template arguments. These restrictions should make a recursive “loop” in compile time impossible… thus no construct exists to do expression templates or many of the constructs that Alexander Alexendrusco
explains in his “modern c++ design” book from 2001. Yet some of the features desribed there, you can achieve in other ways in dyn language (reflection) such as java.
But maybe there are other “hidden” possibilities in there…
“No problem if someone did not want more: he’ll happily use it for containers.”
Totally agree! (I was quite happy just to be able to make a generic pair class (finally) … )
Pradeep Nov 7th 2006 at 01:35 pm 14
Ulrich wrote:
I’m not sure what NetBeans does to get native menubars,
because when I built it myself it didn’t really work (it had Swing-like menubars inside the window). They must have some kind of Swing patch I guess.
You can put Menubar in the right place easily by passing parameters to the java command. This has been available since 10.1
Apple even has a documentation on it.
http://developer.apple.com/documentation/Java/Conceptual/Java131Development/value_add/chapter_6_section_4.html
P
Emil Nov 7th 2006 at 01:36 pm 15
Hi Romainian guy!
“You can actually “const” the parameters. Well, sort of The keyword for that is called final. It won’t prevent the code from modifying the content of your object but it will at least not be able to change the reference.”
No its not the same. The final keyword doesnt do the same as a const decl for a c++ method.
consider this:
(java)
final public String getFoo() {
myString = myString+”Foo”;
return myString;
}
in c++:
std::string getFoo() const {
myString = myString+”Foo”;
return myString;
}
will produce a compilation error… since the internal state of the class is changed.
final is more like the difference in c++ as shown below:
(c++ version of non final java..)
std::string& getFoo() {
someInternalstate++;
return myString;
}
(c++ version of final java..)
const std::string& getFoo() {
someInternalstate++;
return myString;
}
Sorry about the long rant. And yes.. const can mean alot of things in c++…
best regards.
Pradeep Nov 7th 2006 at 01:38 pm 16
BTW, It’s cool Romain Guy is hanging out here. He is one of the Swing developers with actual good taste in UI.
P
Emil Nov 7th 2006 at 01:48 pm 17
Hi again Romanian Guy,
I realized you already knew that when I read your post again..
Sorry for being a smart ass!
/Emil
Andy Nov 7th 2006 at 02:16 pm 18
Hi Sanjay,
I was my understanding that @try/@catch were just syntatic sugar around the old style macros NS_DURING, etc. The old style macros were just wrappers around longjump()/setjump() which don’t do proper stack unwinding.
I’d love to be proved wrong on this.
Andy Nov 7th 2006 at 02:21 pm 19
Hi Ulrich,
It’s good to hear that Swing is progressing and getting better. But almost every Mac application has custom controls and so only being able to do Business UIs is a big hinderance.
Andy Nov 7th 2006 at 02:27 pm 20
Emil,
I had totally forgotten about having no const. That’s probably because I switched from Java to Objective-C and not Java to C++. In C++ I religiously used const to show if something was mutable or not. It was great for determining the author’s intent. As far as I know, Objective-C is also missing const methods.
I also toyed with Java generics a little bit, but I don’t think I really got it. They seemed to be little more than type-casting.
Thanks for the feedback.
Andy Nov 7th 2006 at 02:37 pm 21
Martin,
I’m still not buying the free functions argument.
Why does the language feel the need to force namespaces on me? It’s not horrific, but why the arbitrary distinction? I realize there are technical reasons behind it, but it would be nice if the compiler could hide that from me.
I wasn’t aware of the static import. That’s good information.
As much as I like closures, and would like them in just about any language, I don’t think they’re as easy to understand as pass-by-reference. Maybe it’s because pass-by-reference has been used by a lot of non-functional languages already, and people are familiar with it. Closures, while very nice, can be hard to wrap your head around.
Besides, why can’t I have both?
Thanks for the feedback Martin.
Romain Guy Nov 7th 2006 at 03:10 pm 22
Ulrich,
No harm done
Andy,
You can do much more than just Business UI with Swing. If you haven’t watched the videos I gave a link to in the first comment (and I wouldn’t blame you given the large download size), please take a look at these screenshots:
http://jext.free.fr/aerithosx1.png
http://jext.free.fr/aerithosx2.png
http://jext.free.fr/aerithosx3.png
This is Swing, running on Mac OS X and developed under Windows XP. It’s also full of animations and transitions (that you can obviously see in the videos.) Swing is by far not perfect but it fares much better than most people are willing to admit.
Please note that I am not telling you to use Swing
I’m just saying that Swing is a very versatile and flexible API, especially given its cross-platform nature. And it’s not slow (anymore) and does not have to look like crap 
Andy Nov 7th 2006 at 03:38 pm 23
Hey Romain Guy,
I actually missed the video link the first time I read your comment (I guess I’m blind or something). I’ll go look at it.
Your screen shots are nice, and look Flash-esque. How hard is it to create that UI? Is there source code somewhere? How hard is it to integrate the flashy UI with standard controls?
Joachim Bengtsson Nov 7th 2006 at 06:09 pm 24
I actually really like that ObjC has you calling the super constructor manually. For one thing, in C++ you can’t preprocess constructor arguments before sending them to super, in ObjC you can.
( E g
- (id)initWithFoo:(int)foo;
{
int foo1 = foo * 23.0;
foo1 += [self bar:foo1];
return [super initWithFoo:foo1];
}
or something like that)
Andy Nov 7th 2006 at 06:25 pm 25
Hey Joachim,
Ok, you got me there, it is nice that you can process parameters before you passing them to the parent class. But how often do you really need that? I can count the times in my entire career that I needed that on one hand. Plus there are ways around it in C++, such as calling free functions in the initializer list.
It just seems like a high tax for functionality that isn’t needed all that often. i.e. Make the common case fast (to code).
Thanks for the response.
MrP Nov 7th 2006 at 07:05 pm 26
Andy,
just to clarify, in java there is no such thing as pass by reference. None. Period. _All_ parameters passed to a method are pass by value.
Primitive types, as you correctly describe, send a copy of their value to the method. For object references they also send a copy, but _of the reference_ (not the object) which point to the same object as the caller caller scope, and thus you can modify that object within your method.
This distinction becomes important if you try to write something like a swap method, eg:
public static void swap(Foo a, Foo b)
{
Foo tmp = a;
a = b;
b = tmp;
}
calling this method, you will find that the swap occurs _within_ the method, but not in the caller’s scope, and the caller will find their objects not swapped.
Joachim Bengtsson Nov 8th 2006 at 02:51 am 27
Andy,
I don’t know if it’s because I’m more used to objc than any other language, but I find myself quite often needing parameter preprocessing. Also, I’ve noticed that several of my fellow programmers in my class find themselves, in C++, in situations where they want to preprocess parameters. (And calling free functions is Plain Ugly :P)
I really like Ruby. In Ruby, if you don’t call super explicitly by just running “super” (which calls the super constructor with the same arguments as “you got yourself”), it will be called implicitly. You can also call it explicitly, without arguments (above behaviour) or with any number of arguments. This is really nice. However, I prefer named constructors to implicit and anonymous such.
I prefer:
- (id) initAsPlaceholderFor:(id)foo;
- (id) initReplacing:(id)foo;
to both
def initialize foo
and
MyClass(Foo foo) {…}
MyClass(Foo foo, Boolean shouldReplace) {…}
Joachim Bengtsson Nov 8th 2006 at 02:59 am 28
Also, with explicit super constructor calls, you can return something that *isn’t* an instance of super, for example a singleton instance. In other languages, you may *only* return the instance that was just created, while [[foo alloc] init] might actually return an NSProxy instance, or anything. Cleaner than saying “You must use this static member to create an instance of this class”.
Romain Guy Nov 8th 2006 at 12:25 pm 29
Andy,
We created this whole demo in about two weeks worth of work and we were 2.5 people working on it. There is more to the application than what is shown in the screenshot and videos (the application can generate an applet which shows a fullscreen animation of your travel on a map.)
Almost everything you see in the screenshots are standard controls for which we custmozied the look. The “tasks” are just labels, the navigation bar is made of labels, the photo albums is a regular list, the drop shadow text that shows the description on an album is a standard text area, etc. The only custom controls are the 3D ones and the map viewer.
The source code is available under BSD license at http://aerith.dev.java.net and we have several online presentations that explain how we achieved some of the effects (see http://www.jroller.com/page/gfx?entry=no_fluff_just_stuff_extreme)
Andy Nov 8th 2006 at 01:29 pm 30
Joachim,
I never said calling free functions from initializer lists was pretty, just that it was doable.
I do have to agree with the singleton case. I have a couple of examples in the interpreter (type classes), where I just want one instance. That is handy.
Andy Nov 8th 2006 at 01:30 pm 31
Romain Guy,
Thanks for the links and info. I will check it out.
Martin Nov 9th 2006 at 06:11 am 32
Hello Andy,
as for
> I’m still not buying the free functions argument.
Why not?
> Why does the language feel the need
> to force namespaces on me?
We always had them in form of packages and that was a very good idea - compared to the prefixes we used to apply to classnames in Smalltalk. Sure, you could place classes in the “default package”, but after a few occasions (where I just tried out some Java feature the quick and dirty way) I stopped doing that: Now I *always* place classes in packages. It’s just a routine.
So I guess you would at least want to keep the “free” functions assigned to packages, right? But packages are mapped to diretories, only classes and interfaces are mapped to files (if you are using a file system, that is
)
So, in order to keep the source code in some file we would have to extend the pattern with an extra rule for “free” functions. Plus you would still want some “import feature” for these (unless you dare to work with the default package).
Wouldn’t it be slightly cumbersome to be forced to look for an unknown function in two areas: Classes and packages? And note that the usual scopes of protected or private would not be applicable to functions being “package members”. Confusing? Maybe for some.
Then consider reflection: You would have extend those APIs in order to handle “free” functions and hence bloat the language somewhat further. Just because you don’t want namespaces to be “enforced” upon you (what would you do with that facility? use namspaces anyway in 99.99% of the cases even though not forced to?) And then, as you say:
> It’s not horrific…
Sure
And perhaps that’s why I immediately accepted it as it is saving my energy for thinking up more powerful extensions.
> but why the arbitrary distinction?
Isn’t the introduction of new, even more “free” functions than statics some “arbitrary distinction”, too? And even more so?
> …would be nice if the compiler
> could hide that from me.
Sure. And having static imports is as good as it gets here. Remember that we would need that feature anyway, even for functions that are package members. My guess is that, basically, this feeling of a “lack of free functions” was due to the lack of static imports - which made their use really a bit annoying. Java 5+ and a decent IDE should be able to fix that
Martin Nov 9th 2006 at 06:28 am 33
Hello Mr. Joachim Bengtsson,
as for constructors in Java,
I think, that’s the deal:
They are guaranteed to give you a new object of the requested class. They are the low level feature for doing just that. I couldn’t deny it
If some languages are strict at that, this is not necessarily a bad thing. Objective C does it differently, yes, but in other languages there are other ways to accomplish this.
> In other languages, you may *only* return
> the instance that was just created,
> while [[foo alloc] init] might actually
> return an NSProxy instance, or anything.
Confusing and dangerous if miss this fact because of not knowing Objective C well - but I guess, in all languages you’re bound to learn them before you use them, so that’s ok
But:
> Cleaner than saying “You must use this static
> member to create an instance of this class”.
Why cleaner? Just different. Isn’t it very clean to have a guarantee for what a special thing as a constructor (more precisely: the “new” operator) does? And isn’t it clean to have methods - which were always used for all the kinds of “arbitrary” stuff you need - do the other, less “predictable” things? At least in Java I find it quite clean to make my class’s constructors private, gently pushing its clients towards using a factory method when the want some instance. my 2c.
Anonymous Feb 14th 2007 at 04:49 pm 34
No mention of Matisse? Swing programming couldn’t be easier with it.
XCode 3.0 « PaQueSepas Oct 16th 2007 at 10:37 am 35
[…] Algo que me llama la atención del nuevo XCode 3.0 es que tiene Objective-C 2.0. Y Objective-C 2.0 tiene ya garbage collector. Ya han habido algunos artículos al respecto (inclusive una pequenia comparativa entre Java y Objective-C), que si el garbage collector va a traer como efecto que haya más aplicaciones de mala calidad, que si es una ventaja o desventaja. […]