Hacker News Reader

Comment by bensummers | Hacker News Reader

Also the delegate design pattern, which Cocoa uses to great effect, is nicer to implement in Objective-C than other languages. Instead of having to define a formal interface which is explicitly used and all the member functions implemented, you just have to implement the relevant methods. Whether the delegate implements a method is looked up at runtime rather than checked with static typing.

View on HN

Yes! I first used delegates in Obj-C/Cocoa. When I then learned .NET delegates, my first thought was "Ewww!"

Just looked those up. Sounds, er, fun. I suppose the clean implementation in Objective-C is a side effect of it being an oddly static dynamic language. But the oddness does yield a very nice application framework.

Obj-C delegates look like how smalltalk does delegates.

(Obj-C is basically Smalltalk on top of C with a rocking API).

If you think that is bad try using the Java pattern for implementing delegates, outright nasty. Personally, I like languages that treat methods as first class objects and allow for the passing of them just like any other variable.

I think delegation is one of the least understood, but most powerful techniques in programming. Being able to inject functionality into another routing based on context allows for reusable work-flow while injected context specific work-flow into that routine, but still allowing that context specific work-flow to have access to encapsulated scope outside of the routine.

This is extremely powerful flexibility, that allows a developer to accomplish developing more functionality with less lines of code.

Personally, I like languages that treat methods as first class objects and allow for the passing of them just like any other variable.

Agreed. Which ObjC doesn't entirely do; SELs and IMPs are primitive types rather than objects, which is annoying.

"Being able to inject functionality into another routing based on context allows for reusable work-flow while injected context specific work-flow into that routine, but still allowing that context specific work-flow to have access to encapsulated scope outside of the routine."

I up-voted you even though I was unable to parse this sentence.

First thanks for the up-vote. Let me see if I can try to explain it a little more linearly and see if it helps. You have a generic function that you pass in a reference to another function, the generic function does a generic routine and then calls the reference function at a specific point. The reference function then returns a value that the generic function uses to give it a calculation that it wil use in its routine. The interesting part is the reference function can have scope visibility outside of the generic function. This allows for very loose coupling, where one can inject a function into a master function and all scope for the referenced function can be abstracted away from the generic function. It makes the only hard contract between the two the return value of the referenced function and possibly the parameters. It eliminates the need for interfaces or tight coupling to build systems such as listeners, notifiers, callbacks and event systems.

I hope that helps, if it is just a convoluted, then I am sorry. Delegates are a pretty abstract subject and I may not be the best at explaining them.

This is the result of Objective-C's Smalltalk ancestry: similar design patterns are elegant to achieve in other Smalltalk-inspired languages as well, for example SuperCollider[1] and (to perhaps a lesser extent) Ruby.

[1] http://supercollider.sourceforge.net

Reply on news.ycombinator.com