On Sun, May 17, 2020 at 02:18:30AM -0700, ToddAndMargo via perl6-users wrote: > On 2020-05-17 01:23, Peter Pentchev wrote: > > 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 > > > > Hi Peter, > > Gee Wiz, all I want back is a yes or no answer. > That exception stuff irritates when I get it back. > Tacking .Bool at the end insures I will always get > back a yes or no answer
You said that you would tack Bool at the end in "if" statements, too. I don't know how to tell you more clearly that you do not need to do that. 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
