Hacker News new | ask | show | jobs
by Curmudgel 4262 days ago
> The only way to avoid this IPC-handler-explosion in the design is to define the set of IPC objects a priori and mandate all programs know how to handle them. Then, there are O(1) IPC handlers per program, and adding a new program does not require me to couple its implementation to any other programs. This is effectively what UNIX does: there is one IPC object--a string of bytes.In UNIX-2 I could have more types of objects, but the fact that they're defined independent of the programs means that I will still be "hoping the receiving process understands" when I give it data from arbitrary programs...My point is, trying to enforce OOP on IPC will take away universal program composibility, which is the killer (if not defining) feature of UNIX.

Not necessarily. You could pass S-expressions instead of bytes. Parsing would be much easier, and there would be no loss of generality.

1 comments

Either wc needs to specifically be aware of the structure of the S-expression ls emits in order to know which atom or subtree of atoms make up words and lines, or ls must emit an S-expression with a structure that is globally mandated a priori. The former case loses generality (wc must be aware of ls's behavior), and the latter case gives wc no help in interpreting the S-expression (which is the original problem OP pointed out).