World: r3wp

Sure. In REBOL 2 there are 2 functions, EXISTS? and DIR?, that check 
for whether a file! refers to an existing file and whether the existing 
file is a directory, respectively. Both of these functions wrap around 
QUERY, a low-level native that works very differently between R2 
and R3, mostly because of the port model change. In addition, DIR? 
has a design shortcoming in R2 (mentioned in CureCode ticket #602) 
and both DIR? and EXISTS? share the same bug in QUERY in R3 (#606, 
affects #602 and #604).

All of these combine into a few problems:

- People who want to write file and directory management code that 
is portable between R2 and R3 have trouble doing so.

- Bugs of the kind mentioned in #602 are not likely to be fixed in 
R2, so we have to consider DIR? broken for non-existing directories.

- Using both DIR? and EXISTS? means two QUERY calls, which has overhead, 
particularly for networked files.

- Attempts to get around this using QUERY require completely different 
code in R2 and R3, so wrappers would be nice.


As it specifically relates to 2.7.6, for people who don't care about 
forwards compatibility, there is only one problem:
>> DIR? %nonexistingdirectory/
== false  ; Should be true, unlikely to change

Also, R2 and R3 could use a standard function that does the opposite 
of DIRIZE. Current proposed names are UNDIRIZE or FILEIZE.

Why do we need an undirize when it is already so simply to do such?

>> a: %directory/
== %directory/
>> trim/with a "/"
== %directory

It is simple, as is DIRIZE (look at the source), but we still need 
it.

Sounds like bloat to me.

No bloat in R3. Modules get rid of the bloat. If you don't want it, 
don't include it.

Just seems there is better to focus on than that.

How about working on fixing it so we can modifiy the dates on directories. 
 That would be way more important.

Who says I'm focusing on it? It was less than 5 minutes of work.

Yeah but doesn't sound like your done to me.

With undirize? I am done.

I can't fix problems like modifying the date on directories - that 
is native code, and I just work on mezzanines.

I sure hope all these mezzanines don't get distributed with REBOL. 
 Because even if they are still distributed as a package with the 
main bin then it is still bloat.

Rather, there be a separate distribution for just the main bin and 
then the mezzaines.

When native code is released, I can work on it. The people who currently 
work on native code don't work on what I work on - that is why I 
work on it, so they can focus on what they need to. Division of labor.

Seems were getting to many mezzaines for simply tasks.  Were gonna 
be a laughing stock.  LOL.

don't take that seriously - after all I run a mezzanine thread on 
my site.

We only include the mezzanines we use, and I wouldn't suggest something 
unless there is already a need for it. Your TRIM/with code is wrong, 
btw, we only trim the last / and from a copy at that.

My trim was only an example of the ease at which we can perform tasks 
related to this.

R3 will be less bloated than R2, but you are still missing something: 
you say "the main bin" which assumes that R3 will be distributed 
in a single monolithic binary like it is in R2. Not doing that is 
the reason for the split of the host code. Build your own monolith 
if you like, including whatever functions you need.

Well that would be nice.  We shall wait and see.

The point to making these mezzanines is to make them *well*. The 
fileize code above is the least you can write that does what the 
function is supposed to do. If this is not the case, improve it. 
We are improving REBOL by writing these functions, as they give us 
insight into how the system can be improved - look at the difference 
between the two EXISTS? functions above for an example of this. Simple 
code that you could inline if you need to is what we want.

Think of these as a standard library of helper functions that you 
don't have to use if you don't need to. If you do use them, you can 
count on them working as correctly as the REBOL experts can make 
them work, and as efficiently. Either way REBOL is better.

Yes Brian, but the two exists functions above are necessary because 
a change has been made to the operation of query.  In those cases 
it is necessary to modify mezzanines.

Yeah, I understand the point behind mezzanines which is why I maintain 
a good quantity of them outside of the REBOL distribution.

To me, Parse is the greatest strength of REBOL.

Re 3 mgs back, I don't get your point. The new QUERY is better. The 
mezzanines work the same on the outside (in theory). So?

Yes, I don't dispute that the new query is better at all.

what is your undirize function?

So mezzanines are different on the inside. As long as they work the 
same on the outside, your code doesn't need to change. That is why 
the mezzanines are there. And code that is not part or the REBOL 
distribution is not mezzanine code, just REBOL code. If you want 
it to be mezzanine code (with all of the optimization benefits mezzanine 
code gets), submit it :)

I posted it above as FILEIZE, but here:

undirize: func [
	{Returns a copy of the path with any trailing "/" removed.}
	path [file! string! url!]
][
	path: copy path
	if #"/" = last path [clear back tail path]
	path
]

undirize: func [file [file! sring! url!]][if #"/" = last file [reverse 
remove reverse file]]

typo

Ouch, two reverses :(

yeah

Works well.

I don't doubt it. It is modifying rather than copying, but it looks 
like it works.

Yeah and at less evals then yours.

head clear back tail is much faster than reverse remove reverse. 
All of that reversing is series copying, as is remove from the head 
of a series. If you don't need your function to copy, change reverse 
remove reverse to clear back tail.

See already hammering out better code by talking about it.

Yup :). Also, the return value of mine matters, as it does with DIRIZE, 
while yours is tossed. You wouldn't be able to use yours as a swap-in 
replacement for DIRIZE for non-dirs. Mine is a function, while yours 
is more of a procedure (making the Pascal distinction).

I wouldn't use mine at all for myself ;-)

I'm getting to where I use less and less mezzanines.

At least for the more simply things.

If you add a file on the end of the function you would have a useful 
return value. Then the only difference would be the copying.

My approach is to improve the mezzanines to the point where it actually 
makes sense to use them instead of optimizing them away, or at least 
to the point where their code is good enough to inline. If I don't 
use it in highly optimized code, it doesn't go in.

The simpler and faster I can make them the better. If this means 
imporovements to the natives to make the mezzanines better, then 
any code you write that also uses the natives will also be better. 
And you get good library funnctions too :)

;Just using remove


undirize: func [file [file! string! url!]][if #"/" = last file [remove 
back tail file] file]

We should profile to see which is faster: remove or clear.