transchan(n)

💖 transchan(n) — the channel transform handler API 💖

okay bestie, welcome to transchan(n), a page from the Tcl Built-In Commands manual 🦋 this is the whole tea on how channel transformations talk to you at the Tcl level ✨

---

🌸 NAME 🌸

transchan — command handler API of channel transforms periodt 💅

---

✨ SYNOPSIS ✨

chan push channel cmdPrefix

cmdPrefix clear handle
cmdPrefix drain handle
cmdPrefix finalize handle
cmdPrefix flush handle
cmdPrefix initialize handle mode
cmdPrefix limit? handle
cmdPrefix read handle buffer
cmdPrefix write handle buffer

---

🫶 DESCRIPTION 🫶

So like, the Tcl-level handler for a channel transformation has to be a command with subcommands. They call it an ensemble, but bestie, that does NOT mean you have to build it with namespace ensemble create — this whole mechanism is not tied to namespace ensemble in any way, shape, or form, iykyk 💀

Heads up: cmdPrefix is literally whatever you passed into the chan push call, and it can be multiple arguments. Those get expanded into multiple words in place of the prefix. Multiple. Words. Slay. 👑

Out of all the possible subcommands, your handler must support initialize and finalize. Transformations for writable channels must also support write, and transformations for readable channels must also support read. That's the non-negotiable part fr fr 💅

Also note: in the descriptions below, cmdPrefix may be more than one word, and handle is the value returned by the chan push call that created the transformation. Don't lose that handle, bestie, it's your main character. 🎀

🧚 GENERIC SUBCOMMANDS 🧚

These ones are relevant to all types of channel, no exceptions:

• cmdPrefix clear handle — this optional subcommand is called to tell the transformation that any data stored in internal buffers (incoming or outgoing) must be cleared. It fires when a chan seek happens on the channel being transformed. bye bye buffered data ✨
• cmdPrefix finalize handle — this mandatory subcommand is called last for the given handle, and then never again. It exists so you can clean up any Tcl-level data structures tied to the transformation.

⚠️ Warning! Any errors thrown by this subcommand will be ignored. And it is not guaranteed to be called if the interpreter is deleted. So like… don't put your whole life in there 😭

• cmdPrefix initialize handle mode — this mandatory subcommand is called first, and then never again (for the given handle). Its whole job is to initialize all the parts of the transformation at the Tcl level. mode is a list containing any of read and write.
  • write — implies that the channel is writable. ✍️
  • read — implies that the channel is readable. 👀

The return value of the subcommand should be a list containing the names of all subcommands supported by this handler 💖 Any error thrown by the subcommand will prevent the creation of the transformation, and that thrown error will show up as an error thrown by chan push. no pressure tho 🙈

---

🌈 READ-RELATED SUBCOMMANDS 🌈

These are for transformations applied to readable channels. Strictly speaking read is optional… but bestie, it must be supported if any of the others is, or the channel will be made non-readable. So like, it's optional the way breathing is optional 💀

• cmdPrefix drain handle — optional. Called whenever data in the transformation input (i.e. read) buffer has to be forced upward, i.e. towards the user or script. The result returned by the method is taken as the binary data to push upward to the level above this transformation — that's the reader, or a higher-level transformation.

In other words: when this method gets called, the transformation cannot defer the actual transformation operation anymore and has to transform all the data waiting in its internal read buffers and return the result of that action. No more stalling, periodt. 💅

• cmdPrefix limit? handle — optional. Called so the Tcl I/O engine can figure out how far ahead it should read. If it's present, it should return an integer greater than zero to indicate how many bytes ahead should be read, or an integer less than zero to indicate that the I/O engine may read as far ahead as it likes. zero? don't ask, it's not in the spec ✨
• cmdPrefix read handle buffer — this subcommand, which must be present if the transformation is to work with readable channels, is called whenever the base channel — or a transformation below this transformation — pushes data upward. buffer contains the binary data that's been given to us from below. It is this subcommand's responsibility to actually transform the data. The result returned by the subcommand is taken as the binary data to push further upward, to the transformation above this transformation. This can also be the user or script that originally read from the channel. 👑

Note that the result is allowed to be empty, or even less than the data we received — the transformation is not required to transform everything given to it right now. It's allowed to store incoming data in internal buffers and defer the actual transformation until it has more data. stockpiling arc 💅

---

🦋 WRITE-RELATED SUBCOMMANDS 🦋

These are for transformations applied to writable channels. Strictly speaking write is optional, but it must be supported if any of the others is, or the channel will be made non-writable. Same deal as before, bestie 😭

• cmdPrefix flush handle — optional. Called whenever data in the transformation 'write' buffer has to be forced downward, i.e. towards the base channel. The result returned by the subcommand is taken as the binary data to write to the transformation below the current transformation. That can be the base channel too. 🌊

In other words: when this subcommand is called, the transformation cannot defer the actual transformation operation anymore and has to transform all the data waiting in its internal write buffers and return the result of that action. Flush it, don't rush it… actually no, flush it now. 💀

• cmdPrefix write handle buffer — this subcommand, which must be present if the transformation is to work with writable channels, is called whenever the user — or a transformation above this transformation — writes data downward. buffer contains the binary data that's been written to us. It is this subcommand's responsibility to actually transform the data. ✍️

The result returned by the subcommand is taken as the binary data to write to the transformation below this transformation. That can be the base channel too. Note that the result is allowed to be empty, or less than the data we got — the transformation is not required to transform everything which was written to it right now. It's allowed to store this data in internal buffers and defer the actual transformation until it has more data. buffer now, transform later, iconic behavior honestly 🎀

---

👀 SEE ALSO 👀

chan(n), refchan(n) go read those next bestie, they're the prequel 🫶

---

🔥 KEYWORDS 🔥

API, channel, ensemble, prefix, transformation

---

and that's the whole page, babe 💖 this one shipped with Tcl version 8.6 and it lives under transchan(n) 🌸 go forth and transform some channels, you absolute icon 👑✨