Comments on: A new kind of dir
In R3, I can now type:
>> read %*.r
== [%del-objs.r %t.r %t1.r %test.r]
Our friend Petr is going to like that, eh? I think he requested it in 1999. Or, was it 1998?
Of course, this little change has big implications. The issue is this: is *.r a directory or a file?
Well, in reality it is neither. There is no file or dir called *.r. It is a selector specification pattern (in fact, a little domain language) that most file systems accept.
So, you ask again: Carl, as far as my script functions are concerned, is *.r a dir or a file?
Hey, don't ask me... instead, ask REBOL:
>> dir? %*.r
Ok, good to know. Not a dir.
But... what if I do this clever little check:
>> port: open %*.r
>> print port/scheme/name
Ah ha! So it is a dir!
Yes, it has to be, so that the code:
will return a list of files.
But wait, didn't I just say it wasn't a dir? So now maybe you see why it wasn't part of REBOL previously. "Is it a wave or a particle?" It depends on what you need it to be.
To help with this issue, the dir? function now allows a refinement:
>> dir?/any %*.r ; just like find/any
So, there you go.
If you think we should make this the default behavior for dir? then let me know. Maybe it should be.
But, you and I both know there are more issues lurking. This trivial little change is not so trivial. More to be said; more to be written...
Testing if comments are working again.|
Carl, was it really me? You must have better memory than me. Or I just got used to current Rebol's behavior, which is kind of consistent. By adding remove-each we can pretty fast get unwanted entries out, so ...
But - I do vaguely remember, that Amiga file managers had some kind of patter matching, something really missing with Windows. And as you mentioned dialect, do you think we could get it a bit further and extend the "dialect" to allow something like that? The question is, how would you tell 'read it should use your pattern (e.g. parse grammar). Not sure if it is applicable or even needed, as we can read all, and parse unneded entries out later in user level. It is just that for big directories we will have to read all files, but that is not problem probably in +95% of cases...
* and ? wildcard pattern matching on files would help me greatly in my use of REBOL for file management. Thanks!
As for DIR? being updated to match, look at the usage patterns. I think DIR? is used for two main purposes: Code that operates on values returned from reading a directory, and parameter screening. For the former there would be no difference either way as no filenames returned would have wildcard characters in them - only real directories would be flagged.
For parameter screening, I guess the question is whether you are screening for directories or for filespecs that act like directories. The result of reading a file with wildcards would be the same as reading a directory: A block of filenames. Most of my code would adjust automatically without any changes since that behavioral difference would be all that matters.
I would have to vote for the default behavior of DIR? to match that of READ, for consistency. Not sure what to do with DIRIZE though.
Yes Pekr. Long ago. I remember it well.
Regarding pattern, it is a "compromise"... only because it is so widely used do we allow the * and ? pattern match. It is limited, but useful... esp. for beginners.
Brian, dir? is extended in 3.0. Semantics are not the same as 2.0, but can be used the same way. More on that later.|
As long as it doesn't cause more confusion, I'm all for it. The idiom of read+remove-each for matching is/was very common for me. Then I took the time to do this:
Post a Comment:
You can post a comment here. Keep it on-topic.