Wait, doesn't allow you to subclass its classes from ?

...just one more reason not to use Swift.

(Yes, even @objc classes that inherit from NSObject)

@bugaevc I wonder if making an API so that callers *don't* have to subclass stuff defined in the API is actually the right way forward. When OO got popular it seemed very attractive to think, "yeah, I'll just implement behavior which people can reuse in a derived class", but then it becomes really hard to change the shape of how that behavior is accessed.

@federicomena I've been thinking about it too! An abstract class (a class delegating a part of its functionality to a derived class) would perhaps be better off as a real delegate, a separate object

And you know how in Rust you either have traits (interfaces) or types, but no real inheritance? I've found that I do the same in Kotlin, I either define an interface (perhaps with default implementation of some methods) or a final (non-inheritable) class, and basically don't use inheritance

@bugaevc @federicomena I like to do something like that, where I pass in the dependencies. Event handlers are passed to sources, as opposed to implementing event handling by derivation. The former is more flexible at runtime, too, I think.

@SuperFloppies @federicomena I was actually surprised to find out how event handling works in Cocoa. I've been used to the event/listener pattern, e.g. in Android you do

button.setOnClickListener(new OnClickListener() {
public void onClick(View view){

(that's an anonymous class that implements OnClickListener, like closures in Rust)

in .NET, events — and their handlers, called delegates — are built into the type system.


@SuperFloppies @federicomena similarly, GObject has "signals" that are built in to the type system.

Cocoa uses the target-action pattern instead. When clicked, a button runs the specified action (basically invokes a specified method) on the given target. For example,

[submitButton setTarget: request];
[submitButton setAction: @selector(submit)];

And it'll call [request submit] when tapped. So there's no intermediate listener object — the control performs the action directly.


@bugaevc @SuperFloppies oh, this is nice. I guess it lets you have objects that handle all the callbacks for a certain window or context or whatever.

ObjC's message model is pretty nice... it seemed like such a clean extension to C way back when.

@federicomena @SuperFloppies exactly — you can set up all the controls in a window to work on the window controller object, or you can have the individual listener-like objects (but objc doesn't have inline/anonymous classes, so you'll have to declare them separately), or you can make controls directly manipulate your model (skipping the view/window controller), or you can even make one control manipulate other control.


@federicomena @SuperFloppies
One famous example is you can make a slider and a number input field continuously sync their values, without writing a single line of code, by setting them as each other's targets and -takeIntegerValueFrom: as their actions.


@federicomena @SuperFloppies

(Oh, did I mention? You can set these target-action associations in Interface Builder, by Ctrl-dragging from one control to another, no w/o code. But that's not necessarily a good thing — code is much easier to manage (code review, version control...) than nibs.)

@bugaevc @federicomena @SuperFloppies I remember doing this exact thing with WinAPI, and the best I could come up with was a global mutable "bool not_user_input" to prevent infinite recursion (the slider updates the number in the edit box which in turn causes an update to the slider, and so on).

@YaLTeR @federicomena @SuperFloppies I've no idea about WinAPI, but NSSliderCell and the like only send the event using target-action when it comes from the user, not when the value is changed programmatically (as it's the case with -take{}ValueFrom:). You can of course ask to simulate user input, e.g. with -[NSButtonCell performClick:] (even as an action of some other control!), and then the action would fire.

@bugaevc @YaLTeR @SuperFloppies oh, that's nice. Notifications only on user action sounds very useful.

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either! We adhere to an adapted version of the TootCat Code of Conduct and follow the Toot Café list of blocked instances. Ash is the admin and is supported by Fuzzface, Brian!, and Daniel Glus as moderators. Hosting costs are largely covered by our generous supporters on Patreon – thanks for all the help!