Re: [OT] "Fluent Interface"? Welcome to NeXT
Re: [OT] "Fluent Interface"? Welcome to NeXT
- Subject: Re: [OT] "Fluent Interface"? Welcome to NeXT
- From: Jeff C <email@hidden>
- Date: Fri, 3 Aug 2007 12:14:19 -0400
I just can't help but look at this and think... all we really need is
meaningful and intuitive identifiers.
We've long since been (well mostly) done with languages that limit
the length of identifiers.
If you can't type the identifiers, go take a typing class or get
Mavis Bacon.
The person that has to maintain your code will thank you.
On Aug 3, 2007, at 12:06 PM, Bill Bumgarner wrote:
On Aug 2, 2007, at 8:39 PM, Jeff Laing wrote:
This was a very common idiom in earlier Obj-C. Well before "void"
existed, every C function (and therefore Obj-C method) had to
return a
value. It was common to return self on success, and nil on failure.
That way, method calls could be chained as above.
Yes, I understand that, much like I understand that other common
idiom in
the 70's led to the Y2K nightmares that kept Cobol programmers in
Porsches.
I still wonder, how on earth do you determine "what went wrong"
when you
have a chain of operations like this that just silently stops when
something
fails?
Oh, that was easy...
You just manually break up the chain of calls into individual lines
of code so you can actually step through the individual lines of
code. Which, of course, changes the behavior unless you also
added "foo = " to the head of each "[foo ...]" expression.
Just take....
Button *b = [[[[[Button alloc] initWithFrame: f] setColor: red]
setBorder: 42] setMode: 5];
... and turn it into ...
b = [[Button alloc] initWithFrame: f];
b = [b setColor: red];
b = [b setBorder: 42];
b = [b setMode: 5];
... nothing a quick perl script -- all the rage at the time --
couldn't do in short order with only about a 4 in 100 subtle error
rate!
Seriously, though, where is my "dripping with sarcasm" font?
Bringing this all back around to Cocoa, the pattern of always-
return-a-messageable-object (it wasn't always self) incurred some
additional penalties.
Specifically, as multiple threads of execution became more common,
the pattern implied that every method invocation must be
synchronous; that any two method calls could not be parallelized
because the invocation of the second must follow the first.
With distributed objects, it meant that every method invocation
would, by default, always make a full round trip over the wire.
With a (void) return, the runtime doesn't have to package up a
reply beyond an ACK in the synchronous invocation case.
And, now, what I believe to be the Gem in all of this:
Be explicit when writing Cocoa -- or any other -- code.
Don't use character saving shortcuts -- they'll just create extra
work in debugging.
Don't think you can write a hard to read expression that'll somehow
compile down to faster code. More likely than not, the compiler's
optimizer will do something far faster -- and far more perverse --
than you can and any efforts to do otherwise just makes the
compiler's job harder while complicating later debugging and
maintenance efforts.
Complexity, obscurity, subtlety, and brevity are not a signs of
733t k0ding skillz!!1!!one!
b.bum
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
40earthlink.net
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden