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.
nemokosch I have the impression that this is a matter of eagerness/backtracking 00:32
yes, this should be it: <ws> does not backtrack while \s* can do that no problem 00:53
could you please open an issue about the documentation that neglects the difference?
Tirifto_ If I have a role that’s meant to be exclusively mixed in to subclasses of a given class, how should I put that into code? Would I do best to (1) make the role inherit from the given class with ‘is’, (2) note its purpose down in RakuDoc and call it a day, (3) seriously rethink the structure of my program, or (4) do something else entirely? 18:12
antononcube It seems your "given class" should do the role (with does) . Then all sub-classes are going to also do it. 18:16
Tirifto_ @antononcube, well, the thing is that not all sub-classes should be doing it. 18:53
To be very concrete, I wish to transform a file/directory tree in a particular manner, and I should have objects representing nodes (specifically files and directories), and each of those could be either an input node or an output node. 18:56
So at the end of the day, I’ll have four specific sub-classes: input file, output file, input directory, output directory. Output files/directories, for example, should have common methods, but handle them in different ways. So making an ‘output’ role with stub methods, and mixing it into both sub-classes seemed like the most conceptually clear way to handle this. 19:00
antononcube Have one or intermediate classes for the different roles: For example. If the main class is A and the role class is R, you can have A -> B (does R) -> C1 and A -> C2 . 19:01
@Tirifto If have access to Mermaid-JS and/or MermaidInk see this graph: classDiagram GenericFile OutputRole InputRole GenericFile <|-- GenericOutput GenericFile <|-- GenericInput GenericOutput <.. OutputRole : does GenericInput <.. InputRole : does Concrete1 --|> GenericOutput Concrete2 --|> GenericInput box Concretes Concrete1 Concrete2 end 19:12
Tirifto_ @antononcube Okay, I got it to render (hopefully correctly), and I think I get the idea… but if the only purpose of the generic classes is to be inherited from, why even have them and not mix in the role directly? `o` 20:50
antononcube Well for centralizing the reuse of roles -- I think that is (part of) your original question. 20:53
nemokosch re much earlier discussion about coercion types: now I'm certain it's just a bug. if you define a new class Foo, 'asd' ~~ Foo() will still be true, even though there is clearly no method to coerce from string
Tirifto_ @antononcube Hmmm… well, I don’t think that addresses the concern of that role being tied to a specific superclass conceptually. 21:06
nemokosch well, my two cents would be: think if this relation has anything visible on the interface level; if it doesn't then it probably doesn't matter at all 21:07
it's much more common for a constraint to be like "I guarantee property X always holds" than "I guarantee property X will never hold", that's much less useful to the consumer 21:08
Tirifto_ @nemokosch Yeah, it probably doesn’t matter that much, especially not in my particular use-case. But I was nevertheless curious if Raku might have something to express this relation. 21:22
nemokosch I was thinking whether this could be emulated by visibility rules but Raku mostly has just two visibilities: public and private. I don't know if symbols installed directly into a package have extra constraints but I would assume they are also public, as long as you know the name. 21:28