Re: [OT] "Fluent Interface"? Welcome to NeXT
Re: [OT] "Fluent Interface"? Welcome to NeXT
- Subject: Re: [OT] "Fluent Interface"? Welcome to NeXT
- From: Lee Ann Rucker <email@hidden>
- Date: Thu, 2 Aug 2007 20:08:26 -0700
On 2.8.2007, at 20:00, Clark Cox 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.
And Smalltalk, though in this case it would be cleaner to use
semicolons to cascade, rather than use the automatic ^self feature.
customer newOrder
addLine: (Line newLine:6 product: "TAL");
addLine: ((Line newLine: 5 product: "HPK") skippable);
addLine: (Line newLine:3 product: "LGV").
Though I suppose it could be done with lots of parens:
((customer newOrder
addLine: (Line newLine:6 product: "TAL"))
addLine: ((Line newLine: 5 product: "HPK") skippable))
addLine: (Line newLine:3 product: "LGV").
Since sending a message (that returns an object) to nil is essentially
a no-op, the first method to return nil (indicating failure) will
break the chain.
On the other hand, perhaps skippable() is a method of the order that
modifies the last item in the order and returns the order. Or its
a method
of the customer that modifies the last item in the current order.
Thats
about as counter-intuitive as I can imagine, unless you commit to
doing your
coding in this cascaded style.
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?
--
Clark S. Cox III
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
_______________________________________________
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