On Sat, May 16, 2020 at 06:57:53PM -0700, ToddAndMargo via perl6-users wrote:
On 2020-05-16 17:44, Peter Pentchev wrote:
On Sat, May 16, 2020 at 03:19:05PM -0700, ToddAndMargo via perl6-users wrote:
On 2020-05-16 06:38, Peter Pentchev wrote:
$ raku *-e* "your one-liner script here"
And also you might want to put some quotes around the paths to let Raku
know that those are strings and not some identifiers or something.
G'luck,
Peter
Hi Peter,
This is what goofed me up:
$ alias p5
alias p5='perl -E'
$ alias p6
alias p6='perl6 -e'
I have no such feature on the Windows side and had
forgot about it.
Also, if you tack a .Bool on the end of IO.d, you
get back True or False, instead of the useless True
or Crash. I updates my perl6.IO.txt keeper file.
And IO.e also works for directories
What you're doing with "tacking .Bool at the end" is usually not
necessary to do explicitly, because most people do not "say" the result
of .d or .e, but use it in an if, for, while or some such conditional
statement, in which case Raku automatically converts the expression to
a boolean, i.e. tacks a .Bool at the end.
The reason .d and .e return a failure otherwise is that in some cases
they may be used not in a conditional statement, but as a kind of
assertion - "I really, really think that at this point this variable
should contain a valid path to an existing directory, but if something
went wrong in my program and the variable does not contain that, I do
not want the program to go on, it would be useless, I *want* it to raise
an exception when the value is used". At least that's what I think;
I *know* that the people who rewrote .IO in v6.d are on this list, so
please correct me if I'm wrong :)
But the most common use of .d, .e, .f and similar, the most common by
a very large margin, is in conditionals, where Raku does the conversion
to a boolean value automatically.
G'luck,
Peter
Hi Peter,
My big issues is that want to check to see if something
is there, then take appropriate measures based on what
I am doing. Crashing is not what I want. If I should
exit based on what I find, I want the control over it.
So use .d in a boolean context (if, while, etc).
In my "if" statements, I will use Bool anyway as it
will force the issue. And will alert me that there
is something else going on that I should be aware of
(fail).
That's *exactly* the opposite of what I thought I explained, but
you do you, I guess.
Now I have to look up f.
Found it. If you use the Bool, it returns a False
for directories. Cool.
It is documented to return true for files, so yes, it would return false
for directories.
Thank you for the detailed explanation. Very useful
and helpful!
Just out of curiosity
https://docs.raku.org/routine/d
(IO::Path) method d
Defined as:
method d(--> Bool:D)
Returns True if the invocant is a path that
exists and is a directory. The method will
fail with X::IO::DoesNotExist if the path points to
a non-existent filesystem entity.
Where in the definition
method d(--> Bool:D)
does it state True or Fail? It states "Bool". Is
something missing?
The definition does not list all the exceptions that a method or
function can throw, and for good reason - people have learned their
lessons from the Java world, where this, while it did have some very
limited use, very quickly drove programmers to just say "... raises
Exception" on everything, making it essentially useless.
OK, in more words for people who may not have any Java programming
experience: they tried to make programmers list any exceptions that may
be raised from their methods, with the expectation that programmers
would check the documentation for any exceptions raised by the functions
and methods that they call, decide which ones they want to handle and
which ones they want to propagate upwards, and then list the ones that
they propatage and the ones that they raise themselves. However, in some
cases, like when using several library functions from several
third-party libraries, it turned out that the programmer said "oh come
on, I can't keep up with all the changes they make to their libraries,
they keep adding more and more exceptions; nah, I'll just say that my
method can throw *any* kind of exception under the Sun and be done with
it!".
Now Rust and Go are trying almost the same thing, but in a better way,
although I've seen the "propagate it, I don't care what it is!"
mentality in both Rust ("just do .unwrap(), who cares") and Go ("is the
returned value an error? if so, return/propagate it, I don't care!")
programs (not all of them, of course).
I think that proper documentation is a better way than forcing
declarations of the errors returned, and that's what Raku does.
It does not list the exception in the method, it talks about it in
the text description. Of course, if the Raku development team has more
insights in why they chose this way, and the reasons are not what
I wrote here, please correct me :)
G'luck,
Peter
