In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Right, and I called my abstract stream "void *source". :)
It isn't really abstract though as it only understand types of streams
that the parser author had thought of. An abstract stream would have a
vtable or something so that the parser didn't have to know anything
about where the data was coming from, thus decoupling the parser more
from the text it is parsing. It would also be typesafe.
> That means another function in the API. I suppose perl_parse_string() and
> perl_parse_file() are valid options. I'd rather keep the API that embedders
> will be using as small as possible, but two functions with simple names and
> pameters may be better than one function with mildly odd parameters in the
> non-trivial case.
I would probably suggest something like this:
int perl_parse(PerlInterp *interp, PerlStream *source)
{
...
}
int perl_parse_string(PerlInterp *interp, const char *source)
{
PerlStream *stream = new_string_stream(source);
return perl_parse(interp, stream);
}
int perl_parse_file(PerlInterp *interp, const char *filename)
{
PerlStream *stream = new_file_stream(filename, "r");
return perl_parse(interp, stream);
}
You are of course quite right that it adds functions to the API but
is the number of functions in the API critical? I would have thought
that the above provides a good trade off between simplicity for most
people and power for those that need it whilst still maintaining
type safety and maximum extensibility for things we havn't thought
of yet.
We might also still want a flags word to each of those routine for
things like your UTF8 flag.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
...F u cn rd ths u cnt spl wrth a dm!
