Tcl Source Code

Ticket Change Details
Login
Overview

Artifact ID: 119039cfb1a7a933046ac0a297d39bd3311c79993732fe963643dbb2634fe9bc
Ticket: 7be97a685975ec271a02518a0d88c6bc121f8df6
Reviewing chan.n changes
User & Date: apnadkarni 2024-06-19 17:33:29
Changes

  1. closedate changed to: "2460481.23159082"
  2. closer changed to: "apnadkarni"
  3. icomment:
    While I agree with the rest of dgp's comments, I do think it is important to distinguish between the channel and a "token" that identifies it, whether we call it a channel name or channel id. This is analogous to files and file descriptors, or perhaps more appropriately, Sys V streams, which might be the closest functionally to channels.
    
    A Sys V stream or a Tcl channel is a programming construct that transports data (some hand waving here) and supports operations like read/write and transforms. The channel name/id is something used to identify an instance of such a construct. The two are not the same, and there need not even be a 1-1 relation between them. Consider if we had the equivalent of dup() in Tcl. We would then still have a single channel, as our data transfer construct, but now we have two identifiers/names for it. Calling close on the channel name would not terminate the channel, but the identifier would no longer reference it.
    
    In Windows terms, what we are currently calling a channel id/name would be a channel handle. In Unix terms, it would be akin to a file descriptor. In any case the point is the channel is distinct from whatever is used to identify it, whether that is id, name, handle or descriptor.
    
    Having said that I think **when the context is obvious** it would be all right to use "channel" as a synonym for the identifier if it reads better.
    
  4. login: "apnadkarni"
  5. mimetype: "text/x-markdown"