I don't really like either of these, but something better seems doesn't seem
easy to come up with.
Tucker suggested:
>Reason: The Streams.Storage.Bounded package is provided as an alternative
>to the Streams.Storage.Unbounded package, but with more predictable memory
>usage.
The "but" here is clunky, as there really isn't anything that we're opposing
to.
Without it, the original problem returns.
Vincent suggested:
>The Streams.Storage.Bounded package is provided in order to make available
>an alternative means to store streams which has more predicable memory
usage
>than the Streams.Storage.Unbounded package.
We've never talked about "storing streams", and that's not an accident. It's
not the streams that are getting stored, but rather the data sent to them.
These packages are just an implementation of streams that don't use any
files. Thus, they are just an in-memory implementation -- but we don't use
that description, either, because "memory" isn't well-defined (in an RM
sense).
Probably we need a more aggressive reordering:
The alternative package Streams.Storage.Bounded provides more predictable
memory
usage than the Streams.Storage.Unbounded package.
Maybe even drop the alternative and explain the trade-offs better:
The package Streams.Storage.Bounded provides more predictable memory usage
than
the Streams.Storage.Unbounded package, at the cost of needing to determine a
maximum number of stream elements that can be stored.
Randy.
________________________________________________________
You have received this message because you subscribed to the Ada-Comment
mailing list. To leave the Ada-Comment list, send an email with
'leave Ada-Comment' in the body to [email protected]. For help
on the other commands available, send 'help Ada-Comment' to the same address.
Problems? Send mail to [email protected]. This list is operated by the
Ada Resource Association, Inc., PO Box 8685, New York NY 10116-8685.
