hook(n)

πŸ“¦
version 2.0 Β· 2 versions
, in fedora 43, fedora 44, nixos 26.05, nixpkgs unstable

🌸 hook(n) β€” Hooks 🌸

okay bestie, so this is the manual page for hook, and it lives in section n of the manual, which is the Tcl/Tk side of the world in case you were wondering. it's giving ✨ Subject/Observer pattern ✨ and honestly? iconic. let's get into it.


✨ NAME ✨

hook β€” Hooks πŸ’…


✨ SYNOPSIS ✨

package require Tcl 8.5 9

package require hook ?0.3?

hook bind ?subject? ?hook? ?observer? ?cmdPrefix?

hook call subject hook ?args...?

hook forget object

hook cget option

hook configure option value ...

✨ DESCRIPTION ✨

so this package hands you the hook ensemble command, and what it does is implement the Subject/Observer pattern. no cap. 🫢

here's the tea: subjects β€” and a subject can literally be a module, an object, a widget, whatever honestly β€” get to synchronously call hooks. and those hooks can be bound to however many subscribers you want, and those subscribers are called observers. a subject can call any number of distinct hooks, and any number of observers can bind callbacks to a particular hook that's called by a particular subject. hook bindings can be queried, and they can be deleted. that's the whole vibe. πŸ’–

just so we're clear: this man page is a reference only. it's not a tutorial, it's the receipts. πŸ“œ

✨ CONCEPTS ✨

🌈 INTRODUCTION 🌈

okay so Tcl modules usually send notifications to other modules in one of two ways: via Tk events, or via callback options like the text widget's -yscrollcommand option. and like… both of those have issues bestie. Tk events are only available in Tk (rude), and callback options require tight coupling between the module sending the notification and the module receiving it. 😭

but loose coupling between sender and receiver is often desirable! in Model/View/Controller terms: a View can send a command (stemming from user input) to the Controller, and the Controller updates the Model. then the Model can call a hook, and all the relevant Views subscribe to it. so the Model is decoupled from the Views, and honestly the Model doesn't even need to know whether any Views exist at all. main character energy for the Model fr fr. πŸ‘‘

at present, Tcl/Tk has no standard mechanism for implementing loose coupling of this kind. so this package defines a new command, hook, which implements just such a mechanism. slay. ✨


🌸 BINDINGS 🌸

the hook command manages a whole collection of hook bindings. and a hook binding has four elements, bestie β€” count 'em:

  1. A subject: the name of the entity that will be calling the hook.
  2. The hook itself. a hook usually reflects some occurrence in the life of the subject that other entities might care to know about. a hook has a name, and may also have arguments. hook names are arbitrary strings. and heads up β€” each subject must document the names and arguments of the hooks it can call. that's on the subject, not on you. πŸ“
  3. The name of the observer that wishes to receive the hook from the subject.
  4. A command prefix to which the hook arguments will be appended when the binding is executed.

πŸ¦‹ SUBJECTS AND OBSERVERS πŸ¦‹

for convenience, this document collectively refers to subjects and observers as objects, while placing no requirements on how these objects are actually implemented. and when we say object we mean it loosely β€” an object can be:

  • a TclOO or Snit or XOTcl object
  • a Tcl command
  • a namespace
  • a module
  • a pseudo-object managed by some other object (like how tags are managed by the Tk text widget)
  • or simply a well-known name

subject and observer names are arbitrary strings. however β€” and this is the important part β€” since hook might be used at the package level, it's necessary to have conventions that avoid name collisions between packages written by different people. 😀

therefore, any subject or observer name used in core or package level code should look like a Tcl command name, and should be defined in a namespace owned by the package. consider, for example, an ensemble command ::foo that creates a set of pseudo-objects and uses hook to send notifications. the pseudo-objects have names that are not commands and exist in their own namespace, rather like file handles do. to avoid name collisions with subjects defined by other packages, users of hook, these ::foo handles should have names like ::foo::1, ::foo::2, and so on. πŸŽ€

and because object names are arbitrary strings, application code can use whatever additional conventions are dictated by the needs of the application. you do you, bestie. πŸ’œ


okay that's the concepts section done β€” there's still more of this page coming, so don't go anywhere πŸ’–

✨ REFERENCE ✨

Hook gives you these commands, bestie, no cap: πŸ’–

hook bind ?subject? ?hook? ?observer? ?cmdPrefix?

This subcommand is the whole create/update/delete/query situation for hook bindings. ✨

  • Called with no arguments, it returns a list of the subjects with hooks to which observers are currently bound.
  • Called with one argument, a subject, it returns a list of the subject's hooks to which observers are currently bound.
  • Called with two arguments, a subject and a hook, it returns a list of the observers which are currently bound to this subject and hook.
  • Called with three arguments, a subject, a hook, and an observer, it returns the binding proper, the command prefix to be called when the hook is called, or the empty string if there is no such binding.
  • Called with four arguments, it creates, updates, or deletes a binding. If cmdPrefix is the empty string, it deletes any existing binding for the subject, hook, and observer; nothing is returned. Otherwise, cmdPrefix must be a command prefix taking as many additional arguments as are documented for the subject and hook. The binding is added or updated, and the observer is returned.

If the observer is the empty string, "", it will create a new binding using an automatically generated observer name of the form ::hook::ob<number>. The automatically generated name will be returned, and can be used to query, update, and delete the binding as usual. If automated observer names are always used, the observer name effectively becomes a unique binding ID. slay.

It is possible to call hook bind to create or delete a binding to a subject and hook while in an observer binding for that same subject and hook. The following rules determine what happens when

hook bind $s $h $o $binding

is called during the execution of

hook call $s $h

[1] No binding is ever called after it is deleted.

[2] When a binding is called, the most recently given command prefix is always used.

[3] The set of observers whose bindings are to be called is determined when this method begins to execute, and does not change thereafter, except that deleted bindings are not called.

In particular:

[1] If $o's binding to $s and $h is deleted, and $o's binding has not yet been called during this execution of

hook call $s $h

it will not be called. (Note that it might already have been called; and in all likelihood, it is probably deleting itself.)

[2] If $o changes the command prefix that's bound to $s and $h, and if $o's binding has not yet been called during this execution of

hook call $s $h

the new binding will be called when the time comes. (But again, it is probably $o's binding that is making the change.)

[3] If a new observer is bound to $s and $h, its binding will not be called until the next invocation of

hook call $s $h

hook call subject hook ?args...?

This command is called when the named subject wishes to call the named hook. All relevant bindings are called with the specified arguments in the global namespace. Note that the bindings are called synchronously, before the command returns; this allows the args to include references to entities that will be cleaned up as soon as the hook has been called. ✨

The order in which the bindings are called is not guaranteed. If sequence among observers must be preserved, define one observer and have its bindings call the other callbacks directly in the proper sequence.

Because the hook mechanism is intended to support loose coupling, it is presumed that the subject has no knowledge of the observers, nor any expectation regarding return values. This has a number of implications:

[1] hook call returns the empty string.

[2] Normal return values from observer bindings are ignored.

[3] Errors and other exceptional returns propagate normally by default. This will rarely be what is wanted, because the subjects usually have no knowledge of the observers and will therefore have no particular competence at handling their errors. That makes it an application issue, and so applications will usually want to define an -errorcommand.

If the -errorcommand configuration option has a non-empty value, its value will be invoked for all errors and other exceptional returns in observer bindings. See hook configure, below, for more information on configuration options.

hook forget object

This command deletes any existing bindings in which the named object appears as either the subject or the observer. Bindings deleted by this method will never be called again. In particular,

[1] If an observer is forgotten during a call to hook call, any uncalled binding it might have had to the relevant subject and hook will not be called subsequently.

[2] If a subject $s is forgotten during a call to

hook call $s $h

then hook call will return as soon as the current binding returns. No further bindings will be called.

hook cget option

This command returns the value of one of the hook command's configuration options. πŸŽ€

hook configure option value ...

This command sets the value of one or more of the hook command's configuration options:

  • -errorcommand cmdPrefix β€” If the value of this option is the empty string, "", then errors and other exception returns in binding scripts are propagated normally. Otherwise, it must be a command prefix taking three additional arguments:
    • [1] a 4-element list {subject hook arglist observer},
    • [2] the result string, and
    • [3] the return options dictionary.

Given this information, the -errorcommand can choose to log the error, call interp bgerror, delete the errant binding (thus preventing the error from arising a second time) and so forth. iconic error-handling behavior, honestly.

  • -tracecommand cmdPrefix β€” The option's value should be a command prefix taking four arguments:
    • [1] a subject,
    • [2] a hook,
    • [3] a list of the hook's argument values, and
    • [4] a list of objects the hook was called for.

The command will be called for each hook that is called. This allows the application to trace hook execution for debugging purposes. πŸ¦‹

🌸 EXAMPLE 🌸

The ::model module calls the <Update> hook in response to commands that change the model's data:

hook call ::model <Update>

The .view megawidget displays the model state, and needs to know about model updates. Consequently, it subscribes to the ::model's <Update> hook.

hook bind ::model <Update> .view [list .view ModelUpdate]

When the ::model calls the hook, the .views ModelUpdate subcommand will be called.

Later the .view megawidget is destroyed. In its destructor, it tells the hook that it no longer exists:

hook forget .view

All bindings involving .view are deleted.

πŸ’– CREDITS πŸ’–

Hook has been designed and implemented by William H. Duquette. πŸ‘‘

πŸ› BUGS, IDEAS, FEEDBACK πŸ›

This document, and the package it describes, will undoubtedly contain bugs and other problems. Please report such in the category hook of the Tcllib Trackers [http://core.tcl.tk/tcllib/reportlist]. Please also report any ideas for enhancements you may have for either package and/or documentation.

When proposing code changes, please provide unified diffs, i.e the output of diff -u.

Note further that attachments are strongly preferred over inlined patches. Attachments can be made by going to the Edit form of the ticket immediately after its creation, and then using the left-most button in the secondary navigation bar.

πŸ‘€ SEE ALSO πŸ‘€

uevent(n)

πŸ”‘ KEYWORDS πŸ”‘

callback, event, hook, observer, producer, publisher, subject, subscriber, uevent

πŸ—‚οΈ CATEGORY πŸ—‚οΈ

Programming tools

Copyright (c) 2010, by William H. Duquette


And that's the whole page, bestie πŸ’… β€” signing off with tcllib version 0.3, page hook(n). The footer's date slot is lowkey MIA, but the source/version said what it said. Stay hooked. πŸ’–βœ¨

πŸ“¦ where this page comes from