[00:29] Is it possible to have a FQN (Fully Qualified Name) on a custom operator? [00:29] Let's say I have this as a module: [00:29] ``` [00:29] unit module MyModule; [00:29] sub postfix: ($n) is export { say $n * 2 } [00:29] ``` [00:29] I don't want to use , not ... but not sure how to set the FQN. [00:29] I thought this would work, but it doesn't. [00:29] ``` [00:29] need MyModule; [00:29] 1MyModule:ABC; # I thought it would print 2, but not go. [00:29] ``` [00:52] two colons <@425053968864116761> [01:20] *** deoac joined [01:21] Thank you, guifa [01:25] *** deoac left [01:34] *** frost joined [02:56] *** kjp joined [02:57] *** lucs_ joined [03:03] *** lucs left [03:03] *** kjp_ left [03:33] sorry, yeah, I miswrote my example. I tried with two colons and it does not work. [04:08] *** discord-raku-bot left [04:09] *** discord-raku-bot joined [04:38] *** Kaipei left [06:36] I don't know why this would work [07:19] the only "magic" about it is that ABC is inside a certain quoting, otherwise postfix: at the beginning is absolutely a part of the name [07:21] So I would be actually surprised if MyModule::ABC worked [07:23] m: sub postfix: ($n) { say $n * 2 }; say 1ABC; [07:23] checking the space [07:23] lmao [07:23] m: sub postfix: ($n) { say $n * 2 }; say 1 ABC; [07:24] then maybe start a new process? [07:25] 😤 [07:25] m: sub postfix: ($n) { say $n * 2 }; say 1 ABC; [07:25] something is very not fine with the bot again, I'd say [07:59] *** dakkar joined [08:47] pelevesque: I don't think so, but in order to do that you have to write `our sub ...` otherwise you won't be able to access it; `is export` exports the sub so in your script you can write `2ABC`. [08:47] After adding `our`, you will be able to access the sub via `&MyModule::postfix:`. [08:47] If the goal is not exporting the sub, then in the script you can do `my &postfix: = &MyModule::postfix:; 2DEF` [09:28] *** Kaipei joined [10:55] *** Kaipei is now known as Kaiepi [11:24] *** ilbelkyr is now known as nicole [11:50] *** discord-raku-bot left [11:50] *** discord-raku-bot joined [12:21] *** frost left [12:57] *** lizmat left [12:57] Ah this is exactly what I wanted... Big thanks! [12:59] > is export exports the sub so in your script you can write 2ABC. [12:59] what did you mean by that, by the way? [13:01] for me, this reads as if `is export` made the operator behave like an operator and this is surely not true [13:02] and I wouldn't assume this was the supposed message but then what was it? [13:11] *** frost joined [13:17] The operator is just an example - not a particular one I will/would use. [13:17] What I wanted to know is if was possible to force using an FQN like it is for classes. Just to avoid polluting the namespace. For example, if someone made an operator ABC, but you already have it, you could still pull it in using FQN and give it another name. CIAvash shows exactly what I wanted. [13:19] I get that, I'm just curious about the quoted part [13:19] if you `need` it, no but if you `use` it, yes it is true [13:20] if you don't do either, then also no [13:21] sure [13:22] I don't get what `our` did and what `is export` did [13:22] I didn't think `our` is a way to share data with _dependents_, I thought it's a way to share data _within your module_ [13:24] `our` adds the operator to the symbol table of the module; so it's not only lexical in Module but also reachable as Module::postfix: [13:24] " what did you mean by..." <- if `sub postfix: ($n) is export { say $n * 2 }` is in module `MyModule` and you use `use MyModule;` in another file, then in that file you have access to `ABC` because it gets exported by default. You can make it optional by passing a tag to `export`. [13:25] `is export` makes it so that when `import`ed, it gets installed to the importer's lexical scope [13:25] and `use` = `need` + `import` [13:27] so this double accounting is thanks to this thing called the "symbol table"... I never understood this [13:30] I wanted to ask what inspired this two-faced approach but then I realized there was something like this in Javascript at least, and probably it could be argued that namespaces in the C++ legacy are also something like this "symbol table" [13:30] and most importantly that I never understood the motive of this in any of these languages 😅 [13:34] And btw classes can be used by their FQN because they are our scoped by default. [13:36] I will have to think more about this anyway. I rarely ever use modules, or even classes; not much use in 50 liner automation scripts [13:40] I knew classes were set to is export by default, but didn't know they were our scoped by default - or is that essentially the same thing? [13:44] Apparently no [13:45] Separate things. They are not exported by default. Maybe that can be said about the units that are `use`d or imported. [13:46] It something is exported but not our'd, it can only be accessed as something local... no? [13:48] Import adds stuff to your lexical scope... but like [13:48] Isn't this like writing import * in Python? Lol [13:52] How would `import only_function_i_care_about from epic_module` look like? [13:52] yes, but only things are set to be exported by default. you can make things optional and let the user import/use them if they want to. [13:54] Must be something with a colon [13:55] in module: `sub f is export(:f) {}`. in another file: `use MyModule :f` [13:58] *** lizmat joined [14:02] *** frost left [14:04] I read in the raku documentation that classes were set to by default. [14:05] class A { } [14:05] is exported, as it is short for: [14:05] our class A { } [14:05] my class A {} [14:05] is *not* exported, and thus only visible in the scope it is defined in [14:07] oh... I thought it was short for [14:07] class A is export {} [14:07] the docs fooled me, I'll read them again. [14:07] That is from: https://docs.raku.org/language/modules [14:09] not exported by default in the sense that they can't be used without fully qualified name, but yes they are `our` by default. [14:09] ya, I got confused and thought it means by default. [14:11] Ya, I got confused and thought it meant by default. [14:11] I need another coffee... my mind is exploding. [14:53] modules are a headache [16:39] *** dakkar left [16:42] Oof [16:44] Anyway, the phrasing is problematic [16:44] They are not "exported" but "package-scoped" [17:54] We can do what other programming languages do and distinguish them by calling them `export` and `qualified export` [18:19] But it's not export unless you _also_ specify the `is export` trait [18:21] Or well... is it? <:cameliathink:897316667653247057> [18:27] technically it is, even though the name is not there. [18:38] so can you always use our-scoped things from another module if you happen to know their name? [18:42] Yes, I think that is the whole point. qualified exports keep your namespace clean and avoid name clashes. [18:42] in case of clashes, there's always the new "from" module [18:43] https://raku.land/zef:lizmat/from [18:45] offline for a bit [18:45] *** lizmat left [18:46] well it's a bit... tricky that "package scoping" is some sort of (namespaced) superglobal, apparently [18:48] so they are rather "public to the module" than "private to the module" 😄 [18:48] Lizmat is full of surprises [18:49] lizmat: That's great [18:50] I don't know if an issue is open for it or not, but something that bothers me is `enum`s exporting types by default. [19:14] *** Kaiepi left [19:14] *** Kaiepi joined [19:44] *** lizmat joined [21:47] *** Kaipei joined [21:50] *** Kaiepi left [23:22] *** deoac joined [23:23]         $foo = 42; [23:23] I would like to create a string that reads: [23:23]         "The variable $foo has the value of 42." [23:23] How do I stringify a variable name? [23:27] $foo.VAR.name