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 -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
