Hi,

what I will not like is this:

>> split-path %./a
== [%./ %a]
>> split-path %a
== [%./ %a]

,because the latter may mean something slightly different, than
the former. I would prefer the following instead:

>> split-path %./a
== [%./ %a]
>> split-path %a
== [none %a]

(or something similar taking the difference into account)

My reason is this:

if I write something like:

include %a.r

I don't mean the same as

include %./a.r

instead I want Include to search the desired file in its path in
the former case and pick the file in the current directory in the
latter case.

Regards
    Ladislav


----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 05, 2000 6:24 PM
Subject: [REBOL] RFC: Split-Path


> Request for Comments on Split-Path Revision
> -------------------------------------------
>
> Issue: Should split-path be changed?
>
> Discussion:
>
> Split-path currently returns the last element of a path,
regardless of whether it is a file or directory.  That is:
>
> >> split-path %a/b/c
> == [%a/b/ %c]
>
> >> split-path %a/b/c/
> == [%a/b/ %c/]
>
> This allows writing iterative code like:
>
> >> path: %/a/b/c/d
> == %/a/b/c/d
> >> while [path <> %/] [set [path file] split-path path print
file]
> d
> c/
> b/
> a/
>
> (Note, this example also shows another problem with
split-path... in that it has no regular iterative termination
condition.  If you provided a path of %a/b/c/d this code would
loop forever, because the path would reduce to %./ not %/ )
>
> However, you would normally think that a split path type of
function would separate the directory path from the file name
itself.  This would take %a/b/c/ and return a directory path of
%a/b/c/ and a file of none (not a file of %"", which is a file
with no name).  However, you loose the iterative "peeling" shown
above.
>
> Since split-path has other issues that we will be fixing very
soon, I would like to get your comments on this issue soon.  Do
not consider legacy with existing code base.  It is better to
correct this problem today, rather than when the child is 20.
>
> -Carl
> "Dad"
>


Reply via email to