687 karma · joined November 21, 2018
That kind of chicanery isn't unique to JS, by the way, which I mention because of the unfair malignment of JS in the original article. Smalltalk-80 syntactically has blocks, but the code in a block is just compiled into the surrounding method and the block invocation is a fancy GOTO statement.
While Javascript is usually maligned fairly, in this case I think it's unfair. The JS design learned from Self that one of Smalltalk's accidental sources of complexity was having classes as an object-like piece of syntax when they can be built out of objects themselves. JS has a more object-oriented design than some of the other examples of "object-oriented languages" presented without comment in the article.
[As an aside: I don't think programming languages can be functional, object-oriented, or otherwise paradigmatic. I think program designs can have those properties, and programming languages can support or hinder expressing those properties clearly.]
Of course they'd actually be pulled down by law enforcement much quicker than that if all their content mods left.
Sadly around the time this history comes to an end OUCS (now IT Services) abandoned much of its work with bespoke open source development to become the Microsoft money funnel it is now. I say "sadly" not just out of a preference for free software: the way in which this was done deeply affected the mental health of some of the staff involved.
I use this pattern because then I can trust _everything_ in a collection. If an object, even an object that represents emptiness, receives a message, it will handle it and do something, even where that something represents emptiness.
- (id)thingThatSometimesWorks:(NSError *)error;
You can chain these to your heart's content. The one that fails sets the error and returns nil; following messages are sent to nil which does nothing and a particular characteristic of doing nothing is that it doesn't overwrite the error that was set. So you still get to see the error when the workflow finishes.
As an objective-C programmer, I also have a tool in my toolbox which gives NSNull the same message-swallowing behaviour as nil.
@implementation NSNull(GJLNilReceiver)
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector { return [super methodSignatureForSelector:aSelector] ?: [NSMethodSignature signatureWithObjCTypes:"@@:"]; }
- (void)forwardInvocation:(NSInvocation *)anInvocation { [anInvocation invokeWithTarget:nil]; }
@end