 |
|||||||||
|
|||||||||
|
|
When Objective-C 2.0 came out, I was as giddy as a school girl. Mainly because it came with some features that, having spent the last 7 years of my life writing .NET code, I could not live without. These features included garbage collection, the concept of properties, and the ability to refer to those properties with dot-notation syntax. All of those combined made Objective-C 2.0 feel very familiar and gave me warm fuzzies when I would switch from C# to ObjC and back again.
Last night I was reading a little of Aaron Hillegass' book (third edition) and I noticed that he spends about a paragraph illustrating that there is a dot-notation syntax for accessing object properties, but he actually refers to that syntax as silly and then goes on to say that he will not be using that syntax at all in his book.
Looking at it from his point of view, the point of view of someone who has worked exclusively with Objective-C for a very long time, I can see his point of view. However, from the point of view of programmers looking to make the switch from the .NET world to the Cocoa world, this syntax isn't silly, it's pure gold.
Take a look at this line of C# code:
this.Power = bob.Power+12;
Pretty straightforward. Nothing out of the ordinary - just setting the Power property of the current object to Bob's power plus 12. Everybody who is familiar with C# will know exactly what this line of code does. Now take a look at that line of code in traditional Objective-C:
[self setPower:[bob power]+12];
I can totally see where Aaaron is coming from - this line of Objective-C is very clear and very self-documenting. You are setting the "power" property of "self" (equivalent to "this" in C#) to the power property of the bob object plus 12. There are a couple of things here that a C# programmer will dislike. First, it uses the "setXXX" syntax which looks so much like Java it triggers my gag reflex. I have nothing against Java personally, I just dislike using it for the vast majority of tasks (though for some back-end tasks it still remains quite useful, but that's another topic for another post).
The real problem here is grammar. A C# programmer expects properties to be nouns and they expect methods to be verbs. Not just C#, but any object-oriented programming language with robust property syntax that abstracts getters/setters (e.g. not Java) will have the same grammer assumptions. Objective-C, on the other hand, treats everything like a verb. Messages passed to objects are verbs, and accessing a property for get or a set is still treated like a verb.
With that said, let's take a look at what the same line of code looks like in Objective-C using the dot syntax:
self.power = bob.power+12;
A little more straightforward, isn't it? (at least to a programmer who did not learn how to program using Objective-C).
In short, I can see why programmers who cut their teeth on Objective-C would feel that the property notation is silly, because their grammar has always been about verbs (messages). They think in messages. However, programmers coming to the Mac from other platforms such as the .NET Framework think in terms of verbs and nouns, and the dot syntax removes that one extra translation step that needs to be done every time they access a property and goes a long way toward removing the intimidation factor of Cocoa and Objective-C 2.0.
So, I will continue to use the dot syntax and I think that people who refuse to use the dot syntax have plenty of valid reasons for doing so. However, doing so in a public way runs the risk of alienating a lot of potential newcomers to the Mac platform by adding confusion when none is necessary.
Speaking of .NET and ObjC...Are you still working on a book that uses both?
I'm looking for a good way to transition my .NET experience to ObjC. If
you are still working on the book and would like some feedback from someone
with that perspective, I'd be glad to assist.
I am not working on that book, no... I'm working on another book that I
think people will find ridiculously useful (provided you're a .NET
programmer). I am still looking for a better, alternate medium for
delivering my dogma on converting from .NET to Cocoa... so if you have any
ideas, I would love to hear them.
I would really would love to see something specifically for transitioning
from .NET to ObjC, I'm trying to do that on my own time and having a hard
time.
The dot notation is a foe without a doubt. While it may appear easier and
cleaner to coders coming over to Objective-C it is masking the reality of
what is going on. when a coder calls self.blah = 12, it is NOT setting a
property! It is sending a message to the self object of setBlah:12. This
can be tested by creating a setter method manually and logging the call.
Every C# developer knows that setting a property is NOT working with an
iVar directly, also. They know for a fact that bob.Size = 21; is actually
calling the object's internal setSize method (you can see this in the IL
code that is generated when you a compile an object). If the C# developer
doesn't know this about their own native languge, they have no business
learning a new one :) In short, your point is valid, but my point is that
C# developers don't currently, and never have, thought that setting a
property was a direct iVar access - they've always known that under the
hood the setter code is being invoked.
I think there's a subtle distinction between the two styles, such that one
isn't redundant syntax for the other. The accessor notation (/[foo
setBar:]) does indeed call methods. But the property syntax (foo.bar)
might not be calling methods. It may indeed call accessor methods, but
then again it might be doing KVC, it might be doing some clever lazy
property magic, it might even be doing some secret future property magic
which is only available in the 10.7 runtime. The point is that whatever it
really does, you can be confident that the _property_ bar of the _object_
foo has indeed been used.
The problem with the . notation is that it looks like a noun, or looks like
it is setting a property, but it is actually sending a message. The
property notation evolved out of public member variables (or properties as
they were called in some languages). The idea of public member variables is
bad because it ties your implementation to your interface. To get around
this developers started using setters and getters to protect their member
variables and to give them the flexibility to add side effects or
validation. The trouble with getters and setters is that you end up doing a
lot of typing for something that is a very common operation. So now you
have property constructs that save you the typing but still create the
getters and setters behind the scenes. This could be thought of as the best
of both worlds as you save the typing but still allows for a flexible
implementation behind the interface. The trouble is that properties imply
member variables and may lead to assumptions by the users of your
interface, the main assumption being that setting a property is side effect
free. This is not always the case, therefore it is more correct and less
confusing to use the method call (or message) syntax because that is what
is actually happening in your code.
That's awesome. I've got to say that's one of the best explanations of the
dot notation in terms of Objective-C that I've seen/heard. I'm beginning to
like the dot notation less and less ;)
The problem with dot notation in Objective-C is not with the simple example
that you give, but when you mix it up with standard Obj-C notation in
larger more complex code snippets. Particularly when you are dealing with
structs, the notation can actually be harder to read as you are dealing
with two, very different notations:
I tend toward foe. Having learned Basic then 6502 then MS Basic then Quick
Basic then C then 8086 then C++ and finally Objective-C (and others along
the way), I finally found a language that was easy to understand what was
going on just by looking at the code. I am not a fan of code obfuscation
(some call it templates, operator over-loading, function overloading and
such) and find the "dot" syntax of properties in Obj-C 2.0 to be another
form of obfuscation. Is it referencing a C++ class? a struct? an Obj-C
Object? I simply don't know and I have to go find out if I ant to know.
Many times it does not mater, enough of the time... It does.
Come on kids, hop off the high horse.
We had *exactly* the same pontificating from the Java snobs when C#
appeared, on exactly the same subject. This from a group of people who
subsequently failed miserably to implement generics in a way that is
actually useful. But I digress.
Properties provide a useful abstraction - and when setting a property
involves side effects, those side effects should be part of the abstraction
and intrinsic to the user's understanding of what the property represents
(and yes, used sparingly). There is no more reason to reflect the message
sending in the syntax than to directly refer to registers and addresses.
There's a little problem with ambiguity with this syntax, that does not
exist in other OOP languages such as C# and Java. Namely it's that of
structs vs objects. When you look at the code "self.power = bob.power+12;",
how do you know whether self (well, this is a bad example, ignore the
obvious) and bob are objects or structs? You just can't. "struct { int
power; } self, bob; self.power = bob.power+12;" would work just as well.
Hmm, small nitpick, but C# has the same issue. You can't tell the
difference, just by looking, that bob.name is a struct member access or a
class member access. That said, you rarely see structs used in the wild in
C# other than special-purpose occasions.
First, I agree with author - DOT syntax much simpler and easier to read.
For everyone. But apologists of Obj-C looks like fanatics of 'passing
message' religion. Actually, 'messaging' is just a CONCEPTION, nothing
else. It's 'engine' of language implementation, but who said that SYNTAX
must be absolutely the same? Syntax made FOR HUMANS, not for engine. This
is why we have widely used 'syntactic sugar' everywhere - because it clears
code => clears your mind. If is a message 'b' to the object 'a', who
cares how it looks? 'a.b' is not a crime, not a conception violation - just
simplifying of your life.
Hope ppl will share my opinion, not as usual just closing eyes.
