Formal Properties

Ahhh, yes. Formal Properties in a programming language are something that all mainstream .Net (and Delphi) developers have come to know and love. It is quite easy to take something so simple for granted, especially if you are used to programming in .Net languages.

Its also very easy to miss them when you switch to other languages that do (or did) not support formal properties. Take Objective-C, for instance. It has been knighted by Apple as the "core" language of the Mac OS platform, and has been fairly well regarded by folks who can get past its lack of Namespace support and its rather odd method call syntax. It pretty fast and if Obj-C doesn't have the features you need, you can simply include a regular, run-of-the-mill C or C++ header file, and continue on your way. What it didn't have before Objective-C Version 2.0 was Formal Properties.

You can't possibly believe the ruckus adding formal properties caused in the Objective-C community. It would have been similar to putting a directive in C# called #SCREW_STRICT_TYPING (which I personally thing should happen) to turn on dynamic language-style late binding. The whole thing is, now you can get the Obj-C preprocessor to synthesize properties for you, much like with C#'s oh-so-sweet automatic properties. That isn't what ticked off the purists, though. They changed the syntax for accessing properties. It used to work like this:

MyWonderfulClass *wonderfulClass = [[[MyWonderfulClass alloc] init] autorelease];

//Set a property here.
[wonderfulClass setCoolProperty: @"Valuable Data"];
//Get a property value here.
NSString *data = [wonderfulClass coolProperty];

And that still works great, if you know the pattern. If you created getters/setters and didn't follow the pattern, the development tools wouldn't see your properties.  The new syntax in Obj-C looks just like it does in C# or VB. You access the properties like this:

MyWonderfulClass *wonderfulClass = [[[MyWonderfultClass alloc] init] autorelease];

//Set a property here.
wonderfulClass.CoolProperty = @"Valuable Data";
//Get a property here.
NSString *data = wonderfulClass.CoolProperty;

And that is what caused all the fuss. Some folks though it was too...C#-ish, others just thought it was ugly, and out of character for the Objective-C language.  Some thought it was great, because they didn't have to type square brackets for properties anymore.

Now, for those of you who are more C#-ish and don't really understand all of the Objective-C square-bracket mania, I'll give you the short C# low-down. The first line in the code samples is similar to saying this in C#:

using(MyWonderfulClass wonderfulClass = new MyWonderfulClass())
{

}

Specifically, the square brackets indicate the Objective-C equivalent of a function call in C#, except Objective-C doesn't do direct function calls on its own objects. It will for ANSI C functions and C++ functions, but Objective-C objects are special. Objective-C sends a message to the object and the object responds. I thought that was all conceptual mumbo-jumbo when I was first learning it, but as it turns out, it really does send messages to the objects and the objects respond. If you want to know more about how Objective-C works, see this article on Wikipedia, and if that really isn't enough for you, see theauthoritative source at Apple's developer network site.

Now, back to properties. In the Java world, they do what they did in old-school Objective-C (and C++ before that). Specifically, for properties you should follow a pattern for your getter/setter functions. In Java parlance, it is called Bean pattern. And just like everything Java, the documentation makes it out to be a whole lot more complicated than it really is. It works by defining the expected signatures for "property" getter and "property" setter functions so tools like IDE's can figure out what the heck you're doing. The problem with that approach, as far as I can see, is that if you don't know about the pattern, you are going to be frustrated with it until you either figure out what that pattern is, or see Eclipse or NetBeans do it for you, and if you see the IDE do it for you, you may not understand why it does things that way, which I consider to be a distinct problem.

Contrast to VB, C#, and now Objective-C, where you have the pattern hard-wired into the language. You know what a property is when you glance at it (in VB because it has the Captain Obvious keyword of PROPERTY plastered all over it). Formal property support is even engrained into the CLR itself. All you have to do is look at how you pull properties out of an unknown object to see how very formalized properties are in the .Net world.

Basically, the philosophical difference between formal and informal properties is the same philosophical debate that Ruby on Rails and subsequently ASP.Net MVC brings to the world of web development. Do you like Convention over Configuration? Do you prefer formalized, compiler checkable specifications?

Personally, I prefer formal properties the way they are implemented in .Net over what Java uses, because I can save myself some icky-looking parens when I chain together property-gets and method on the ends of properties, but that is, admittedly trivial and wouldn't stop me from using Java if I thought it had a clear advantage over .Net for development. The best way to decide, is of course, to use the different languages and make the choice for yourself.

Have fun coding!