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.

> 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

Thanks for the links and info. I will check it out.

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.

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)

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) {…}

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.