On Fri, Sep 12, 2003 at 10:29:04AM +0300, Vladimir Lipskiy wrote:
> > People make mistakes. Perhaps you should produce some errors if a user
> > strays outside these rules. Garbage in, garbage out: Bad. Garbage in,
> > error out: Good.
>
> It really does that. I mean that it returns a "" when it suspects its
> arguments to be wrong.
>
> > I'll admit to not knowing the general error philosophy of Parrot ops.
>
> It could throw an internal exception, but ... I am not convinced we should
> switch to that sort of indicating errors. Though what kind of errors it
> ought to provide is a subject to be arguing about.
This does sound like something that should be covered by some sort of
"How should ops handle bad input" design document. If there is such a
beast, do what it recommends. If there isn't, there should be one.
> > What if I feed you:
> >
> > concat_dirnames("VOL1:[dir.dir]", "VOL2:[dir.dir]")
> >
> > Well, I suppose that's simple, its an error since you can't usefully
> > concatenate two absolute directories. Anyhow, the point is is an *error*.
>
> Yes, and since concat_dirnames() isn't supposed to concatenate anything
> but dirnames.
Are you saying:
concat_dirnames("C:\foo", "bar") == error?
> > But I was unclear. I meant the other way around.
> >
> > concat_dirnames("b", ":my disk:a");
> >
> > Trying to concatenate an absolute directory onto a relative one should
> > produce an error.
>
> What do you mean by "absolute directory"?
/foo
C:\foo
[foo]
VOL:[foo]
\foo
etc...
Which isn't clear from the example I gave above since ":mydisk:a" is
ambiguous on MacOS.
To be clearer: concat_dirnames("b", "/foo") == error.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/
Here's hoping you don't harbor a death wish!
