On Mon, Nov 26, 2018 at 6:26 PM Trey Harris <t...@lopsa.org> wrote:
>
>
>
> On Mon, Nov 26, 2018 at 04:56 Fernando Santagata <nando.santag...@gmail.com>
> wrote:
>>
>> On Sun, Nov 25, 2018 at 5:34 PM Brad Gilbert <b2gi...@gmail.com> wrote:
>>>
>>> The reason `dir('a', test => { .IO.d })` doesn't work like you expect
>>> is that it is passed strings.
>>
>>
>> Thank you!
>> I could have inferred that from the declaration of the 'test' argument here
>> https://docs.perl6.org/routine/dir where the test is being done against '.'
>> and '..', two strings:
>>
>>> sub dir(Cool $path = '.', Mu :$test = none('.', '..'))
>>> method dir(IO::Path:D: Mu :$test = none('.', '..'))
>>
>>
>> but I guess it's a long stretch.
>> Maybe a note in the docs would be useful to others.
>>
>>>
>>> I would argue that inside of the `test` that `$*CWD` should be set to
>>> `a`, and/or the values should be IO objects.
>>> (They are going to become IO objects eventually anyway.)
>>
>>
>> Indeed I think that even tough one can do any kind of test on the
>> directory's content, the most usual ones are those using the file test
>> operators, so defaulting to IO is probably more useful than defaulting to
>> Str.
>
>
> I'm not sure that's true. I think it's a question of following the Principle
> of Least Surprise.
Exactly, the way it works right now is surprising (to new Perl 6 programmers).
It even took me a few seconds to realize what the problem was, and
I've been learning Perl 6 for about a decade.
> The only substantive difference between `my $i = "foobar".IO` and `my $s =
> "foobar"` besides needing to stick the `.IO` in when you want to do IO-y
> things with `$s` is that `$i` retains the knowledge of $*CWD at the time of
> instantiation. But `dir` always returns paths that stringify _relative to
> `$*CWD` at the time of the `dir` call._ Notice the difference between
> `$i.gist` (which, if evaluated, will not consistently re-create the original
> object) and `$i.perl` (which will):
>
> > $f.gist
> "foobar".IO
> > $i.perl
> IO::Path.new("foobar", :SPEC(IO::Spec::Unix),
> :CWD("/home/trey/perl6/rakudo-star"))
> > chdir "/tmp"
> "/tmp".IO
> > $f.gist
> "foobar".IO
> > $i.perl
> IO::Path.new("foobar", :SPEC(IO::Spec::Unix),
> :CWD("/home/trey/perl6/rakudo-star"))
>
> The string, OTOH, is also relative to the `$*CWD` at the time of the `dir()`
> call, but if you call `.IO` on it after changing directories, the path object
> is interpreted relative to the new directory. This is unsurprising; what
> _would be_ surprising is if a string changed as a result of external program
> state.
I was only talking about the object within the `:test` argument of the
`dir` call.
The resulting sequence wouldn't change at all.
> Large-scale file-munging operations have always been squarely in Perl's
> wheelhouse, and doing fancy operations with complex subtrees (such as
> syncing, normalizing, archiving, collating, etc.) are common.
Precisely why I suggested changing it.
The way it works now is harder to use than it could be.
> The string doesn't offer as much in the way of features, but I think it
> behaves much more predictably when doing these sorts of operations. If you
> `chdir $dest` after the `dir` but before doing your munging, then you must
> remember to prepend the old working directory if you need to access the
> original file (i.e., `$src = $*CWD; for @files -> $f { $src.add($f) ... }`),
> while the new files would just be `$f`. If you don't change directories, then
> you must say `$dest.add($f)` to refer to the new files, while the old file is
> just `$f`. But in either case, it's unsurprising and predictable.
Actually Str behaves less predictably than an IO object for the `test` argument.
If you want to compare it stringwise, do so and it works:
my $dir = IO::Path( 'b', :CWD('a'.IO) );
say $dir eq 'b'; # True
If you want to see if it is a directory, just ask it:
say $dir.d; # True
`.gist` doesn't stringify an object, it returns enough information for
a human to be able to figure out what the object is.
When you do stringy operations on an IO::Path object (or any object),
it calls the `.Str` method not `.gist`.
The only things which implicitly call `.gist` is `say` and `note`.
Now what I proposed was having the CWD set to the directory being
examined inside of `test`, which is a different `CWD` than the result
of the `dir` call.
> say dir('a'):test( {temp $*CWD = 'a'.IO; .IO.d && .IO ~~ none(<. ..>)} )
("a/b".IO)
> say dir('a', :test( {temp $*CWD = 'a'.IO; .IO.d && .IO ~~
none(<. ..>)} ))».CWD
(/home/brad)
Note that `none(<. ..>)` still worked just fine against such an
object. (the default `:test` argument)
I also didn't say they had to be IO objects, just that the CWD should
be inside of the directory of the dir being tested within the `:test`
argument.
>
> If, OTOH, these were IO objects, if you changed directories, you'd think from
> the gist that you'd do the same. And if you don't change directories, you
> _could_ do the same (`$dest = "/destdir".IO; $dest.add($f)` works using the
> gist). But if you do change directories, it's now the _old file_ that's just
> `$f`; the new file becomes `$*CWD.add($f)`. This feels quite strange and
> surprising to me.
The result of `dir()` is already a sequence of IO::Path objects with a
predetermined CWD.
> say $*CWD
"/home/brad".IO
> my $dir = dir('a').first( *.basename eq 'b' );
> say $dir.CWD;
/home/brad
> indir 'a'.IO, { say $*CWD; say $dir.CWD }
"/home/brad/a".IO
/home/brad # notice that it didn't change
I was only talking about changing what gets passed to the `:test`
argument of the `dir` call.
> The very slight keystroke-saving convenience of not requiring the outputs of
> `dir` to be followed with `.IO` before doing IO operations on individual IO
> objects in-place doesn't seem worth the strangeness of their behavior when
> doing bulk operations on them from a distance.
That isn't what we are talking about.
We are talking about the `:test` argument being harder to write and
understand than it should be.
Right now you have to append the directory you are looking at before calling .IO
By either setting $*CWD, or creating an IO object with :CWD set; it
makes such code easier to understand.
The behaviour wouldn't change for Str based comparisons, so I don't
understand how this relates to my solution.
> (I was thinking through possible have-your-cake-and-eat-it-too solutions like
> `.gist` and `.path` of IO objects created from strings changing their string
> representation if and only if you changed working directories and these all
> seem to just Waterbed Complexify the problem elsewhere. Perhaps someone can
> come up with an everybody-wins solution—but except for moving the filetest
> operations into `Cool` so they work like in Perl 5, a ship that's already
> sailed, I can't think of one.)
I don't understand what you are talking about here.
