I’d push back on this, just a little: This article as a whole is describing a form of metaprogramming, and one that looks pretty useful, IMO. I think exposing user interactions as a set of commands is a very useful way to model things, and being able to introspect said list is also very useful.
I actually quite like this. I’ll repeat my own understanding if it, because I think the underlying insight is a little under-expressed and thus I had to read the second half twice before I realized what was actually being suggested:
When considering your application API, be thoughtful about maintaining, ideally, a three way distinction between private functions, public functions, and user-facing functions (this is the yeah, duh section)
Ensure that the set of user-facing functions is available at runtime via reflection.
This is the part that I didn’t get at first- the language about ‘distinguishing’ them is a bit ambiguous and might suggest simply a restatement of (1). But the examples make it clear that the article is about the advantages of being able to enumerate and inspect the set of those distinguished functions, which is a more specific and clarifying notion.
I think this is a good explanation. Probably better.
One tiny nit is that it doesn’t necessarily have to be at runtime—you could reflect at compile/dev time. In practice I usually do it at runTime but often do some static stuff with those user functions as well.
It can be helpful to build the UserMethod first, expose it in a Command Palette or via Keyboard Shortcut Interface, and only if it then proves to be useful, design it into the GUI.
This is not far from standard macOS practice: Everything the user can do belongs in the menu bar, each menu item is handled somewhere by a method, and those methods follow a conventional pattern. Only the most important commands also appear in always-visible UI, like a toolbar button, and some others may be progressively disclosed. But the menu bar is the index.
If I had to bet on where I picked up this pattern, it’s probably from Apple land. Would not be surprised if in old code from the 80’s. Anyone know what the terms of art for this parttern are amongst Objective C/Swift programmers?
I think you’d call them action methods. The target-action pattern is one way they’re called. The token “IBAction” identifies action methods for you to wire up in Interface Builder. Targets can be particular objects or the first responder, and the responder chain is implicit beyond that target.
For example and IIRC, the Copy menu item will be bound with the target-action pattern to the -copy: action on the first responder target. When you select Copy from the menu or type ⌘C, the event dispatch will first call the view with typing focus, then if it doesn’t respond (doesn’t implement that method) it recurses to its next responder (superview, usually). A variant of this check is also done when you open the menu. The Copy action will be enabled only if some object on the responder chain responds to -copy:.
I like the concept. Another similarly helpful distinction would be to expose some functions/methods to testing code only, and leave them private otherwise.
Another phrasing: you can bring your API design skills to bear on the problem of interaction design, by having some procedures that correspond 1:1 to things a user will want to do. If you commit to marking those up with an annotation, you can go and enforce that exactly that set of procedures are exposed to automation, reachable from the GUI somewhere, exercised by your integration tests.
Interesting, thanks! UDA’s look like a kind of decorator. I’m a bit of language geek and love all the different terms used in the different languages for similar concepts. Each one adds a slightly different perspective and helps me calibrate things.
Yeah, this is really just basic MVC or separation of concerns. You should have some class whose job is to turn user stuff into business stuff.
I’d push back on this, just a little: This article as a whole is describing a form of metaprogramming, and one that looks pretty useful, IMO. I think exposing user interactions as a set of commands is a very useful way to model things, and being able to introspect said list is also very useful.
I like this idea, and I think that this is part of what
(interactive)provides in Emacs Lisp - the demarcation of a function as a user method.This is a great example. Thanks!
https://www.gnu.org/software/emacs/manual/html_node/elisp/Defining-Commands.html
Usage in emacs codebase: https://github.com/emacs-mirror/emacs/search?q=interactive
I actually quite like this. I’ll repeat my own understanding if it, because I think the underlying insight is a little under-expressed and thus I had to read the second half twice before I realized what was actually being suggested:
When considering your application API, be thoughtful about maintaining, ideally, a three way distinction between private functions, public functions, and user-facing functions (this is the yeah, duh section)
Ensure that the set of user-facing functions is available at runtime via reflection.
This is the part that I didn’t get at first- the language about ‘distinguishing’ them is a bit ambiguous and might suggest simply a restatement of (1). But the examples make it clear that the article is about the advantages of being able to enumerate and inspect the set of those distinguished functions, which is a more specific and clarifying notion.
I think this is a good explanation. Probably better.
One tiny nit is that it doesn’t necessarily have to be at runtime—you could reflect at compile/dev time. In practice I usually do it at runTime but often do some static stuff with those user functions as well.
This is not far from standard macOS practice: Everything the user can do belongs in the menu bar, each menu item is handled somewhere by a method, and those methods follow a conventional pattern. Only the most important commands also appear in always-visible UI, like a toolbar button, and some others may be progressively disclosed. But the menu bar is the index.
If I had to bet on where I picked up this pattern, it’s probably from Apple land. Would not be surprised if in old code from the 80’s. Anyone know what the terms of art for this parttern are amongst Objective C/Swift programmers?
I think you’d call them action methods. The target-action pattern is one way they’re called. The token “IBAction” identifies action methods for you to wire up in Interface Builder. Targets can be particular objects or the first responder, and the responder chain is implicit beyond that target.
For example and IIRC, the Copy menu item will be bound with the target-action pattern to the -copy: action on the first responder target. When you select Copy from the menu or type ⌘C, the event dispatch will first call the view with typing focus, then if it doesn’t respond (doesn’t implement that method) it recurses to its next responder (superview, usually). A variant of this check is also done when you open the menu. The Copy action will be enabled only if some object on the responder chain responds to -copy:.
I like the concept. Another similarly helpful distinction would be to expose some functions/methods to testing code only, and leave them private otherwise.
Isn’t this exactly what AppleScript (or ARexx on the Amiga) is for?
Another phrasing: you can bring your API design skills to bear on the problem of interaction design, by having some procedures that correspond 1:1 to things a user will want to do. If you commit to marking those up with an annotation, you can go and enforce that exactly that set of procedures are exposed to automation, reachable from the GUI somewhere, exercised by your integration tests.
Sounds like d’s UDAs.
Interesting, thanks! UDA’s look like a kind of decorator. I’m a bit of language geek and love all the different terms used in the different languages for similar concepts. Each one adds a slightly different perspective and helps me calibrate things.
https://dlang.org/spec/attribute.html