On Tue, Nov 28, 2000 at 07:03:49PM +0000, Tom Hughes wrote:
> 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.
Agreed.
> Applying the maxim that any software design problem can be solved
> with sufficient levels of abstraction I'd suggest that passing some
A related warning sign is trying to cram different semantic levels or
types into same data. (C's "string model" being perhaps the most
obvious example, getchar() having to be an int is another, "0 but true"
a third...I want a "1 but false" :-)
> 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.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
