file! and url!
[1/2] from: al::bri::xtra::co::nz at: 9-Aug-2002 17:08
I sent in a replacement for 'suffix? to Feedback and they pointed out that
my replacement 'suffix? fails when taking the suffix (extension) of a url!
and comparing it to a file.
Here's Rebol's version of Suffix?:
>> source suffix?
suffix?: func [
{Return the suffix (ext) of a filename or url, else NONE.}
path [any-string!]
][
if all [
path: find/last path #"."
not find path #"/"
] [to-file path]
]
And here's my suggested change:
Suffix?: func [
{Return the extension of a filename or URL, else none.}
Path [file! url!]
] [
all [
Path: find/last Path #"."
not find Path #"/"
Path
]
]
And here's a case where my function fails:
>> %.r = suffix? http://www.rebol.com/test.r
== false
That's because my 'Suffix? keeps the original type of input:
>> type? suffix? http://www.rebol.com/test.r
== url!
A url! value is a superset of file! values. Should a file! type be
comparable to a url! value? Are they the same when they have the same
content?
Should the output of 'to-file on a url! value produce a file! with the
protocol (http: or ftp: etcetera) removed?
At the moment:
>> to-file http://www.rebol.com/test.r
== %http://www.rebol.com/test.r
Which seems a bit odd to me. Perhaps better would be:
>> to-file http://www.rebol.com/test.r
== %//www.rebol.com/test.r
Or, perhaps:
>> to-file http://www.rebol.com/test.r
== %/test.r
Note that this: "http://www.rebol.com" has been removed.
What do people think?
Andrew Martin
ICQ: 26227169 http://valley.150m.com/
[2/2] from: anton:lexicon at: 9-Aug-2002 16:30
So they're saying this is not true:
%.r = to-url %.r
What? I would expect that to be true.
url! and file! are both series! datatypes
(and also both any-string!).
I would expect this not to be true, of course:
%.r == to-url %.r
But then, holy cow! I expected this to be true:
%.r = ".r"
and it isn't, either.
Andrew, I think there is nothing wrong with your suffix?
(except for Path should stay [any-string!]).
I reckon Rebol needs to be changed to meet expectations
there.
But I could be wrong.
Anton.