On Mon, May 26, 2003 at 06:49:15PM -0500, Brian Hurt wrote:
>
> Replying to myself...
>
> On Mon, 26 May 2003, Brian Hurt wrote:
>
> > But you're right, count needs to be an optional thing.
> >
>
> val count: ExtStream.t -> int option
>
> where a return value of Some x means the stream has x elements, and a
> return value of None means that count is not implemented. This has the
> advantage of roping the type checker in to make sure everyone checks for
> the non-implemented version.
You have two types (Enum and Stream) and a clear way to distinguish
them (whether count always makes sense). If you merge them, you push
the distinguishing feature to runtime.
Also, it's not clear what the semantics of count on Stream are. Consider
Stream.of_list; does it do one traversal on creation to take the count?
Does it do it on the first call to count? What if it's on a List with
setcdr? Should count be treated as an expensive or an inexpensive op?
I think it makes sense to create a stream from an enum, but the opposite
is not true. I think we are lucky count is there to remind us. If you
agree with this, then the two types should not be unified.
-- Manos
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
|
Try Searching:
servers, voip, java, networking, microsoft ...
|
|
|
|