Re: [OT] "Fluent Interface"? Welcome to NeXT
Re: [OT] "Fluent Interface"? Welcome to NeXT
- Subject: Re: [OT] "Fluent Interface"? Welcome to NeXT
- From: Brian Willoughby <email@hidden>
- Date: Fri, 3 Aug 2007 09:50:40 -0700
The question of error handling is important, but I think that the
criticisms of these blogs are missing out on an important concept: In
an object-oriented system, the caller should not be tasked with
detecting and handling every possible error. For the most part, the
kinds of errors that we are discussing can be handled by the called
class, using exceptions, and the caller should never continue
executing to completion if there is an error.
Of course, there are times when an error should be handled by the
caller, but that is nearly always as a result of querying status or
attribute state, not an unexpected allocation failure. I am not
saying that these fluent language examples are something to emulate,
but I am saying that the criticisms are equally simplistic and short-
sighted.
Saying that exception handling was bolted on to ObjC as an
afterthought is also a silly criticism. There are many aspects of C+
+ and Java which are self-contradictory, awkward, or non-orthogonal.
C++ is particularly troublesome in the way it generates code behind
the scenes causing behavior that can surprise all but the most
informed programmers. My point is that Cocoa provides functional
exception handling, even if it does have the shortcomings of Standard
C macros, and the facility should be used to handle unexpected errors
- especially allocation failures.
P.S. (void) existed before Objective-C. It was convention, not lack
of language types, which resulted in the use of (self) or (nil)
instead. I was sad to see message chaining go, but efficient
distributed objects were more useful. Besides, I had rewritten
enough message chains during debugging sessions that I wasn't really
so sad to see that paradigm become deprecated.
Brian Willoughby
Sound Consulting
On Aug 2, 2007, at 20:00, Clark Cox wrote:
On 8/2/07, Jeff Laing <email@hidden> wrote:
Just saw this on Fowler's blog, and it reminded me of old-style
Objective C returning self all the time, and how I was very sad to
see it go in a lot of ways.
One can only hope not. The thing about these pissy examples is
that by
leaving out all error handling, they trivialise the problem then
claim an
elegant solution. If you look at his original method:
how did that skippable() method know what it was applied to - the
assumption
is that the return from the with() was still an order, not an
order line.
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.
Going back to the original, what happens if *any* of those
Product.find()
calls fails? The order goes ahead anyway. In fact, this order
got added to
the customer regardless of whether it managed to get formed at all.
You could have coded the above as something like
[customer addOrder:
[order orderWithLines:
[orderline lineForProduct:@"TAL"
quantity:6],
[orderline lineForProduct:@"HPK"
quantity:5
skippable:YES],
[orderline lineForProduct:@"LGV"
quantity:3],
nil
rush:YES]
];
and I actually see that as being that much better in terms of
readability,
but is it really good form to use this sort of thing in Cocoa;
surely one is
actually going to check errors?
Isn't this just pushing towards a C++ try/catch model which
appears to have
been bolted on to Objective-C as an afterthought?
_______________________________________________
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