0

I want to mark such methods in my application code with a comment that highlights that these methods are expected to get called by the framework / compiler the application is written for, even if the application code itself contains no calls to them.

F.ex. the methods called by an Inversion of Control framework, like the beginRender and afterRender of Apache Tapestry; or the ones of an event-driven language, like the Form_Load of Visual Basic.

I was tempted to say Event handlers but I'm not sure it's correct to limit the concept to events; f.ex. in Tapestry a page rendering triggered by one event (like the click on a link) is composed of several phases and each phase has its own methods, and they get called by the framework; these phases occur in a predefined sequence, so it might be misleading for the reader of my comment if I call "event" each of them.

Sometimes Callback is suggested but I have the doubt that that only applies to a function that gets passed to other functions as an argument.

The only thing the functions / methods I'm talking about have in common is that they get called by the framework / compiler, regardless of whether the developer also codes explicit calls to it or not.

closed as primarily opinion-based by gnat, Thomas Owens Dec 23 '15 at 13:31

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Emacs developers would never even dream of calling this anything else than a hook. The usage extends to other programs from the 1970s and 80s, although not quite so pervasively. – Kilian Foth Dec 23 '15 at 11:36
  • @KilianFoth Hook sounds good, it's unfortunate that it's not so common but so far this is my best option, thanks. If I go for it I would ask you to make it an answer. – SantiBailors Dec 23 '15 at 12:28
  • 1
    @KillianFoth unfortunately, "hook" also commonly means a function which intercepts an API call or event before it reaches its typical destination, e.g. in the Windows API functions SetWindowsHookEx and similar, so I wouldn't use it on this context these days. – Jules Dec 23 '15 at 14:39
  • @Jules Nice point, so hook is not it either. – SantiBailors Dec 23 '15 at 14:48
  • 1
    Re the accepted answer in @gnat's link above, to me this question totally falls into the category "1. What is the name of this well-known concept?". I don't understand how the type of methods I described is not a well-known concept. Just for the record though. – SantiBailors Dec 23 '15 at 15:12
3

As others already pointed out, we do not normally assign an overarching name to these functions. I have heard all of these terms and seen them in action, but so far, no common name that crossed language/platform/framework boundaries seems to have emerged as far as I can tell. But I think it's a fine question nevertheless. As it was said, naming things is hard, but we all agree that it is also important, so here's my take on this:

Hooks are as @Kilian Foth pointed out quite the old-school term and indeed, I haven't heard that term in a long time. There's not really a reason why it went out of fashion as it is still valid, though I have to admit I never really liked the idea of a visual hook for this sort of concept.

Handlers have been named too, however, these do in general have a slightly different semantics in most of the cases I encountered them. Handlers are typically found in correspondence to user interactions (action / button handlers). Event handlers are a slightly more targeted term, which directly corresponds to events. Due to many domains explicictly modelling events, however, I also don't like that as a general term, since it can be confusing to have "event handlers" in the hook/callback sense, when there is no actual "event" involved.

Callbacks are close to hooks, but due to the term have a different directional emphasis. With a hook there is something existing and from the outside you hook into that, whereas a callback is something you pass along and at some time lateron, the other side will reach out to your callback. Other than that, callbacks have fallen out of fashion similarly to hooks with derogatory derived terms like "callback hell" coming to mind.

"Implicitly" is yet another term that already exists for such a case, yet has again a completely different semantics. Check out the Scala language, which offers "implicitly" as a direct language term even. Its meaning though is not that of a hook/callback/whatever we discuss here.

In addition to that, several frameworks do not even bother with names for this purpose. A typical case is the usage of f.ex. Java's reflection API. Consider the Beans standard, in which you have accessor methods (a.k.a. getters). Several frameworks call these methods automatically via reflection and they serve yet another purpose in contrast to all of the above.

As a consequence of this discussion, I would like to argue Obi-Wan-style, that this term is not what you're looking for. As we have seen, the different candidate terms have wildly differing semantics or reasons for being called automatically. It is even disputable what "automatic" means. Since naming is primarily a means to transport meaning, the very use of a term denoting "automatically used function" is questionable.

As soon as you fix some of these variable semantical interpretation options (or if you prefer UML "semantic variation points") though, a term to identify your choices starts to make sense. That's why we do have hooks, event handlers, callbacks, implicit methods, property accessors and what-not. But each of these terms contains more information than the mere fact of "automatic calling", whatever that may be.

  • Urgh... I might end up just writing "Called automatically by Tapestry" then. However, given that for now I'm hooked on hook, what extra information do you think one might receive from hook besides "called automatically" ? I would like to avoid any potential extra meaning. As a side note, good point about hook and callback going out of fashion for no apparent good reason, it's probably just because they were around since long time and new generations like to come up with new terms. – SantiBailors Dec 23 '15 at 13:08
  • 1
    As I point out in the comments to the question, "hook" is used in Microsoft documentation and API names with a slightly different meaning, which could be confusing. – Jules Dec 23 '15 at 14:42
  • I accept this answer now because I'm not sure I can still do that if the question gets closed, and it really seems that there is no conventional name for these functions, just like this answer suggests. It also contains very informative points. – SantiBailors Dec 23 '15 at 15:16
1

They're just … functions. Functions that the rest of the code you've written is already using.

If you're writing an application, then these are already indistinguishable from functions that code you might write in the future will be using.

If you're writing a library, making them private (and optionally providing a public wrapper) is a good way to isolate "functions I'm providing to the library user" from "functions my library uses itself". I then like to call them "internal functions" but that's probably just me.

I will note, however, that the specific examples you've given in your question all happen to be handlers/callbacks/hooks, so if you're not actually hoping for a broader term, that'll do just fine.

Naming things is hard. Sometimes we describe a function based on how we're using it in that context. Sometimes we describe a function based on how it is typically used. Sometimes we describe a function based on how it should always be used. Coming up with a general rule to cover all of these things, without context, is close to pointless. Just make your documentation clear and unambiguous, using as many English words as you need, and you'll be fine.

  • The functions I'm talking about, only the framework calls them, not my code; so I guess it's a matter of what we mean by code "using" a function, however the expression I need is exactly aimed at pointing out that difference. Handler alone doesn't convey the "called automatically" meaning enough for me (probably due to the widespread practice of naming "FooHandler/Manager/Helper" anything that has to do with Foo). Callback might have the problem I mentioned in the question, I don't know yet. Hook is good. BTW the only thing I need to cover is that they get called automatically. – SantiBailors Dec 23 '15 at 12:39
  • @SantiBailors: I think you're overusing/misusing the term "automatically", and that's causing your terminology problem. Every single function in your computer gets called automatically. Computers are automatic. That is their purpose. You're trying to make a distinction where there is none, or, at the very least, making a distinction and giving it the wrong name for the wrong reasons. – Lightness Races in Orbit Dec 23 '15 at 13:13
  • Agreed, computers are automatic and that's their purpose; but the distinction I make is definitely there. However it's true that I might be misusing the term "automatically", I can see that, it's actually overly generic and it doesn't even sound too professional. What expression might fit instead ? The distinction it should represent is between application methods that there is no reason to expect that the framework will call, and application methods that the framework is expected to call. Or I should probably just call them "framework-called methods". – SantiBailors Dec 23 '15 at 13:31
  • @Santi I can't tell you what unambiguous expression to substitute for an ambiguous one, because it's ambiguous, which means I can't know what you mean by it ;) Although at a guess you seem to be triggering the third paragraph of my answer. They're internal functions. They're part of the internals of your library/framework/application and are not for "public consumption". Make them private or hide them in a detail namespace to enforce. – Lightness Races in Orbit Dec 23 '15 at 13:57
  • I'm unable to see how can that distinction be ambiguous, so I don't think any further effort of yours at explaining me can be fruitful, but I appreciated your points. About your last hint, I cannot make those "framework-called" methods private because the framework (Tapestry) wouldn't be able to call them any longer, and for the same reason I cannot alter their name because the name is what allows the framework to know they're there. There would be the same problem for the other example in my question (VB's Form_Load), while I realized that the Javascript one was wrong so I'm removing it. – SantiBailors Dec 23 '15 at 14:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.