5 ms·
> Of you override the dispatch mechanism… AKA Method Swizzling. ObjC developers took advantage of this feature and it was a wild frontier (but illegal in Appl
by FlyingSnake 4y ago
> Of you override the dispatch mechanism…
AKA Method Swizzling. ObjC developers took advantage of this feature and it was a wild frontier (but illegal in Apple’s eyes).
1: https://nshipster.com/method-swizzling/ https://nshipster.com/method-swizzling/
- mpweiher 4y agoMethod swizzling is actually something different: replacing a concrete method definition. There really isn't any good way of messing with the underlying message dispatch mechanism, objc_msgSend() unless you do DYLD interposing or some such hackery. However, objc_msgSend() has enough hooks to allow you to do custom dispatching, but only after the normal lookup has failed. Initially there was -forward:: which essentially gave you a pointer to a stack frame. Later, -forwardInvocation: gave you an NSInvocation, which was the message wrapped in an object. Nice, but slow. Since a lot of time the idea was just to forward the exact same message to another object, we later got a new intercession point that allowed you to return that other object. But again, all these only got activated once ordinary lookup failed, hence NSProxy and friends (objects with very few methods implemented). Oh, and there was the nil class hook: objc_msgSend() short-circuits when the receiver is nil, but for a while you could theoretically set a class to which the messages to nil would be dispatched. I tried it out a couple of times and it worked, but it was never really used, mostly undocumented and has since been removed, AFAICT.
- JamesSwift 4y agoRight, method swizzling is actually "monkey patching" in ruby parlance. You arent replacing the _dispatch mechanism_, you are relying on the fact that its a dynamic lookup to replace that entry in the lookup table at runtime. Which then the dispatch mechanism happily plays along with.
- FlyingSnake 4y agoAh my bad, I jumped the gun without reading the whole comment and it's context.
- pdpi 4y agoThe original Doom was developed on NeXT, so a lot of the tooling (like DoomEd) was written in ObjC. If I recall correctly they abused this whole thing by making proxy objects that would happily call methods across the network, so they had level cooperative editing back in the early 90s (minus all the concurrent edit stuff we take for granted today, of course).
- arcticbull 4y agoCheck out NSProxy :) - fun fact it's the only* other root class in Foundation, a peer of NSObject - and NSDistantObject. Part of the super-deprecated Distributed Objects precursor to XPC. [1] [1] https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/DistrObjects/DistrObjects.html https://developer.apple.com/library/archive/documentation/Co...
- steve1977 4y agoThere was even PDO and a bridge to MS OLE https://en.wikipedia.org/wiki/Portable_Distributed_Objects https://en.wikipedia.org/wiki/Portable_Distributed_Objects Loong long ago…
- pdpi 4y agoI was trying to google for some sort of reference to what I meant, but couldn't find one (found this thread instead...) but NSProxy seems to have been around long enough that it might well be the core of the implementation for what I was talking about.
- retrocryptid 4y agoThank you for not mentioning CORBA.
- retrocryptid 4y agoYes and no. Concurrency was still a problem that got short shrift. But the "overload doesNotUnderstand:, serialize the message and dispatch it over the network" was a fun way to do rpc-ishness in Smalltalk and ObjC before people got hung up on writing IDLs. (Looking at you, CORBA) I'm reminded of Larry Wall's quote: "languages differ not in what they make possible, but in what they make easy." Smalltalk and ObjC made proxy objects easy.