On Wed, Apr 4, 2018 at 8:37 AM, Sven Van Caekenberghe <s...@stfx.eu> wrote:

>
>
> > On 4 Apr 2018, at 17:32, K K Subbu <kksubbu...@gmail.com> wrote:
> >
> > On Wednesday 04 April 2018 04:06 PM, Nicolas Cellier wrote:
> >>> IIRC, someone said it is implemented as 'remaining size being zero'
> >>> and some virtual unix files like /dev/random are zero sized.
> >> Currently, for files other than sdio (stdout, stderr, stdin) it is
> >> effectively defined as:
> >> atEnd := stream position >= stream size
> > I see a confusion between Stream and its underlying collection. Stream
> is an iterator and just does next, nextPut, peek, reset etc. But methods
> like size or atEnd depend on its collection and there is no guarantee that
> this collection has a known and finite size.
> >
> > Essentially, a collection's size may be known and finite, unknown but
> finite size or infinite. This has nothing do with file descriptor being
> std{in,out,err}. If std* is a regular file or special file like /dev/mem,
> /dev/null, it's size is known at open time. With console streams or sysfs
> files, size is unknown until EOT (^D) or NUL is received. Lastly, special
> files like /dev/zero, /dev/random or /proc/cpuinfo don't have a finite size
> but report it as zero (!).
> >
> > [ stream atEnd ] whileFalse: [ stream next. .. ]
> >
> > will only terminate if its collection size is finite. It won't terminate
> for infinite collections.
> >
> > Regards .. Subbu
>
> Good summary, I agree.
>
> Still, what are the semantics of #next - does the caller always have to
> check for nil ? Do we think this is ugly (as the return value is outside
> the domain) ?


The problem is not that the value is outside the domain.  The problem is
that it may be within the domain.  Answering an element within the domain
when there are no more elements is insane.  Not even C does that.


> Do we then still need #atEnd ?
>

For backward compatibility, yes, even if deprecated.  There is so much
existing code that uses it, it'll be useful to have.


> Sven
>

_,,,^..^,,,_
best, Eliot

Reply via email to