This channel is intended for people just starting with the Raku Programming Language (raku.org). Logs are available at irclogs.raku.org/raku-beginner/live.html Set by lizmat on 8 June 2022. |
|||
04:14
librasteve_ left
04:21
human-blip left
05:17
SmokeMachine left
05:18
kjp left
05:19
kjp joined
05:21
SmokeMachine joined
05:34
avuserow left
05:35
avuserow joined
07:12
kjp left
07:13
kjp joined
07:14
kjp left
07:15
kjp joined
14:00
librasteve_ joined
18:17
cliviafreak joined
|
|||
cliviafreak | I'm trying to figure out how to implement value comparison in objects. Is the best way using WHICH and returning a string representation? | 18:18 | |
lizmat | if your objects are so-called value types, then the only you need is to have the WHICH method return an ValueObjAt object | 18:25 | |
docs.raku.org/type/ValueObjAt | |||
method WHICH() { self.^name ~ "|" ~ .... } | 18:26 | ||
18:27
cliviafreak left
18:40
cliviafreak joined
|
|||
cliviafreak | thank you. | 18:40 | |
lizmat | cliviafreak: actually: method WHICH() { ValueObjAt.new(self.^name ~ "|" ~ ....) } # forgot that part | 18:48 | |
18:51
cliviafreak left
18:59
cliviafreak joined
|
|||
cliviafreak | If you return just a string is it treated differently? | 18:59 | |
lizmat | well, it actually might, but not always | 19:00 | |
19:00
msiism joined
|
|||
msiism | To keep myself on track in terms of learning Raku, I've written a little "hangman"-style word guessing game. | 19:02 | |
The code is at www.msiism.org/pb/haHM7E/lt.html. | |||
I'd be very much interested in feedback of virtually any kind, but mostly concerning better use of Raku. | 19:03 | ||
Prefering routines over methods is intentional, by the way. | 19:04 | ||
19:06
cliviafreak left
|
|||
lizmat | msiism: clearly coming from Perl :-) | 19:19 | |
some remarks: many superstitious parens in if / unless in Raku they are not needed | 19:21 | ||
so: if ($a == $attempts) { -> if $a == $attempts { | |||
and what do you have against methods being called on objects? | 19:22 | ||
msiism | Okay, right. I prefer the parentheses around the conditions, though, where possible because I find that more readable. | 19:23 | |
lizmat | also: for 0 .. (chars($word) - 1) -> $i { -> for ^chars($word) -> $i | ||
for case insensitive comparison, you should use fc instead of lc that's more unicode safe | 19:24 | ||
msiism | Okay, will do. | ||
lizmat | but again, what's against using methods? | 19:25 | |
also the "returns Str" is a bit old-fashioned.... it's better to use -> Str inside the signature | |||
so: sub perforate($string) returns Str { -> sub perforate($string -> Str) { | 19:26 | ||
msiism | Concerning methods called on objects, I don't have anything against that per se. I guess it's just that I don't think that way. Also, the other languages I use don't work that way. | ||
lizmat | ok | 19:27 | |
msiism | Oh, right, if I define a type for the return value, it's a good idea to also define input types. | ||
lizmat | also, if you want to make sure you get / return instances, you should add :D to the type | ||
msiism | Okay, I'll read up on that. | ||
lizmat | so: sub perforate($string) returns Str { -> sub perforate(Str:D $string --> Str:D) { | ||
correction on: "so: sub perforate($string) returns Str { -> sub perforate($string -> Str) {" -> sub perforate($string --> Str) { # must be 2 hyphens | 19:28 | ||
msiism | Oh, I see. | 19:29 | |
I had to laugh out loud when you said this looks like coming from Perl, by the way. I've, maybe, written 10 lines of Perl in my life so far. :) | |||
lizmat | also: if ($success == True) { -> if $success | ||
ok, C then ? | |||
msiism | Yeah, it probably looks like scripted C, I thought. | 19:30 | |
lizmat | also, no "return" is needed for the last expression in a block | ||
msiism | Though, the languages I've spent the most time with so far are PHP (abandoned a while ago), sh/Bash, and Racket. | ||
I see. | |||
lizmat | so: return $result; -> $result | 19:31 | |
ok, that's it regarding syntax | |||
msiism | I'd probably prefer `return`, though, because that's less cryptic. I'm trying not to be too cryptic, generally. | 19:32 | |
For my own good… | |||
lizmat | sure... at the moment there's a slight performance penalty on return, but that may well go away in the future | 19:33 | |
just for your understanding: "return" in Raku is implemented as a subroutine, that just happens to mess with the stack | |||
msiism | I see. | 19:34 | |
lizmat | also, for CLI scripts, you might want to have a look at docs.raku.org/routine/MAIN | ||
msiism: I'd say, it's a good start :-) | 19:35 | ||
msiism | Okay, thanks a lot! :) I'll go read and fix stuff now. | 19:36 | |
disbot3 | <nahita3882> on &choose_word: instead of picking an appropriate random index and then indexing the list, you can directly pick from the list, i.e., @list.pick or the subroutine form | 21:37 | |
<nahita3882> they made ^N for 0..N-1 | 21:38 | ||
<nahita3882> instead of iterating over indexes and then indexing a String, you can iterate over its elements after .combing it, e.g., for $string.comb -> $char { ... } | 21:39 | ||
<nahita3882> if you also want the index, .kv is one way: for $string.comb.kv -> $idx, $char { ... } | |||
<nahita3882> instead of $var = $var OP $other, one can do $var OP= $other, e.g., $result ~= $letter | 21:40 | ||
<nahita3882> string interpolation allows say $a, " extra" to be say "$a extra" | 21:41 | ||
msiism | Okay, thanks. | 21:43 | |
Yeah, I know about the compound assignment operators. But, as odd as it may sound, I tend to prefer writing out the formula. | 21:49 | ||
Kind of easier on the brain -- mine at least. | 21:51 | ||
I remember that Ada, for example, deliberately doesn't have those in order to keep code fool-proof. I get the sentiment. | 21:55 | ||
I'll probably be less inclined to do it that way the more I get to know Raku. | 22:05 | ||
22:14
msiism left
23:41
librasteve_ left
|