In article <46-1183202235.20040722005816 / soyabean.com.au>,
  Gavin Sinclair <gsinclair / soyabean.com.au> writes:

> What about this?
>
>   1) read(n):
>        current method; no problem if less than n bytes read,
>        and no blocking
>
>   2) read(n, :noeof):
>        as (1), but raises EOFError on end of file
>
>   3) read(n, :noeof, :pblock):
>        as (2), but *partially* blocks; i.e. blocks only if no data
>        is immediately available
>
>   4) read(n, :exact):
>        as (1), raise some error if less than n bytes read
>        (implies :noeof)
>
>   5) read(n, :exact, :block):
>        as (4), but block until n bytes are available
>
>   6) read(n, :exact, :pblock):
>        as (4), but *partially* block, as per (3)
>
> All methods can accept a String parameter which acts as the receiving
> buffer.  The 'n' parameter must come first; the order of the rest
> doesn't matter.
>
> The naming of "pblock" could definitely be better...

I don't see a difference between 4th and 5th.
I can't understand 6th.

Do you have usecase for them?

I think such symbols based behavior specification tends to allow
specifications no one need.  So it increase the possibility which an
user select an unsuitable combination by mistake.  Also the
implementation should define meanings of all combination of symbols
and implement them, even if a combination is never used.  So it waists
developper resources.
-- 
Tanaka Akira