RE: [OT] "Fluent Interface"? Welcome to NeXT
RE: [OT] "Fluent Interface"? Welcome to NeXT
- Subject: RE: [OT] "Fluent Interface"? Welcome to NeXT
- From: Jeff Laing <email@hidden>
- Date: Mon, 6 Aug 2007 09:16:04 +1000
Brian said:
> 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.
I think this illustrates perfectly the exact problem with the fluent code.
By definition, the order object was created BEFORE the orderlines were
created - otherwise the cascading effect of the calls could not possible
work. Go back and try and work out what time each entity existed and you
can see that throwing an exception out of the orderline methods would have
resulted in the order existing and not being cleaned up even though
*something* went wrong in the process.
Its not possible for the called code to know whether it needs to clean up an
enclosing order or not, unless that method is *only* intended to be used in
this cascaded structure. It *must* fall to the caller, who can catch it via
exceptions but still has to go through the hoohah of working out which
objects it needs to release because its not sure how far it got.
But of course, the magic handling of 'messages to nil' helps out here
because you can rely on none of your pointers containing values unless their
creation assignments actually worked. Reliance on hack 1 to get around hack
2's pattern flaw.
> 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.
I don't see why that makes it a *silly* criticism. Its perfectly valid, as
far as I'm concerned. At least C++ had try/catch right from the start
rather than NS_WHATEVER/NS_FINALLY or was that @try/@catch - when you have
two distinct schemes in the literature, you can tell it was bolted on as an
afterthought. Otherwise they'd have thought about having automatic release
on stack unwind.
Jim Brownfield said:
> ...
> I don't agree with this at all. It seems to me that your presumption
> is that nil represents an error, but there were lots of cases where
> nil was returned intentionally knowing that whomever was calling the
> returned object would not error out, but rather just execute a no-
> op. It was rather elegant, and mixed with a decent exception
> throwing mechanism, not that dangerous either.
I don't see why you think I presume that nil represents an error. That was
what the original defenders of the fluent style suggested, not me. It would
make a lot more sense, from my language designers perspective, if fluent
errors returns an NSCrapWhatHappened object which would respond to every
message with a "hey, something went wrong". That way, you don't rely on the
'messages to nil' hack to *silently* mask problems, but you also don't
collapse because you, at some point, try to NSLog(@"%@",null) and then have
to work backwards to find your failure point.
As to "mixed with a decent exception mechanism", thats pretty much what I
said originally.
I hate to harp on all this, but in my day job, I've just been updating about
20,000 lines of C++ which is scattered with "delete ptr; ptr=NULL;" and
because thats so tedious and gotten wrong so often, we have helper macros of
the form DELETE_AND_NULL(ptr). You know,
inline void DELETE_AND_NULL(void* &p) { delete p; p=NULL; }
which looks aesthetically disgusting, but it always works (oh, and its not
all C++, there are about four distinct memory management schemes in there
for reasons beyond the scope of this forum). Your next reference to p will
result in an access violation - here comes the debugger. But when I use
that same paranoid mechanism in Cocoa, all I get is silence.
The tiny voices in my head keep saying "You should combine a C++ smart
pointer class with Objective C, so that you can just go 'ptr=NULL;' to drop
references safely". *Thats* what I'd rather Apple did than Garbage
Collection which to my mind is laziness, not programming.
_______________________________________________
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