In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The third parameter is the flags parameter, and it's optional. If omitted
> or set to PERL_CHAR_SOURCE, the second parameter is treated as a standard
> null-terminated string. If set to PERL_COUNTED_SOURCE, the second parameter
> is treated as if it points to a stream of bytes, where the first four are
> the length of the source to be read followed by the source. If set to
> PERL_FILE_SOURCE it's assumed to be a FILE *, while if set to
> PERL_GENERATED_SOURCE it's assumed to be a pointer to a function that
> returns a char pointer. If it's OR'd with PERL_UTF8_SOURCE then the stream
> is assumed to be in UTF-8 format instead of platform native.
This all seems a bit horrible to me. That kind of overloading of
multiple meanings onto an argument is often a sign of a bad design
that could be improved.
Applying the maxim that any software design problem can be solved
with sufficient levels of abstraction I'd suggest that passing some
sort of abstract stream pointer would be better. Then there could
be different sorts of streams that provided the source from a string
or a file or whatever other wonderful data source somebody comes up
with.
The common case of parsing a string could of course be simplified
with a small wrapper function that created a string based stream
and then called the main parser entry point.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
...A private sin is not so prejudicial in the world as a public indecency.
