Only if it is clear this is a distinct interface. Pretending 'files'
are peekable is a broken way of looking at files. The fact that
regular files are random access means there is no gaurentee that what
you peek will be what you get, unlike sockets, pipes & so forth.
Pretending 'files' are peekable is a !broken way of looking at files.
What we do with software is "pretend". A compiler or interpreter allows us
to pretend that a computer understands a language it never sees. The malloc()
routine allows us to pretend that brk() doesn't exist. A filesystem is a
massive game of pretend played with disk blocks. I like pretend, but the
grown-up word for it is "abstract". To abstract is to hide irrelevant detail.
I am not interested in looking at Unix files accurately. Unix files are an
irrelevant detail. I am interested in building an abstraction that is useful
for solving my problems. I suggest placing the abstraction into file objects
because that is where it already is.
I was refering to the peeking. It would be needless overhead and
complexity when the author should either use seek or multiple file
objects.
Just how carefully have you considered this position? You can't get multiple
file objects with separate file pointers unless the object they refer to is
seekable (you work it out). And I know you haven't read my other message,
but I'll just point out again that you want me to write OS-specific code for
a problem better solved with an abstraction.
Tracy Tims
tracy@sni.ca