[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion generic streams

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-12-13 05:39:24 CET

On Tue, Dec 12, 2000 at 08:57:10PM -0500, Jim Blandy wrote:
>
> > Even easier:
> >
> > *stream = svn_stream_create(pool, rs, read_string_fn, NULL /* write */,
> > NULL /* seek */);
> >
> > One simple entry point which takes the appropriate functions and the
> > baton.
>
> One problem with this is that, if you want to add another function to
> streams (something that could tell you whether a read would block, for
> example), you need to change all the callers. Greg H's interface
> suits me better.

You can always add "setter" type functions if you add other stream funcs.
However, we don't see it now, we know what these streams are like, and we
can also build the _create() to satisfy the *common* case. Hell, I'd guess
that we mostly do the stream stuff for reading, and that we don't seek, so
I'd bet the write/seek arguments could be shoved over to
svn_stream_create_extended() or somesuch, and leave the create function as a
very bare-simple thing.

IOW, the above format is easier for the common cases than a create/set pair.
But nothing in the above scheme *precludes* the use of setters.

> Guile at one point had a family of scm_make_port_type_FOO functions,
> where FOO was a sequence of letters that indicated which functions it
> expected as arguments. It was supposed to be terse, but it ended up
> just being ugly and hard to read.

If this was Python, then I'd recommend named arguments:

   fin = svn_stream_create(pool, rs, read=my_reader)
   fout = svn_stream_create(pool, rs, write=my_writer)

   fud = svn_stream_create(pool, rs, read=my_reader, write=my_writer,
                           seek=seek_the_bugger,
                           jims_whatzit_func=blarg)

:-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.