🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel! Set by lizmat on 6 September 2022. |
|||
aruniecrisps | i wonder what i'm doing wrong then 🤔 if i can get it to properly parse raku files into an AST then a good chunk of our work is done already @lizmat | 00:03 | |
cdn.discordapp.com/attachments/633...34307& | |||
00:19
xinming left
00:20
xinming joined,
jpn joined
00:25
jpn left
01:25
derpydoo left
|
|||
_grenzo | what was the command that produced that error? | 01:40 | |
nvm I see it right at the top | 01:42 | ||
and is Moneys in your include paths? | 01:43 | ||
01:56
jpn joined
02:01
jpn left
02:03
jpn joined
02:08
jpn left
|
|||
aruniecrisps | it's not, but it shouldn't matter, what i'm trying to do is just get the AST | 02:11 | |
[Coke] | the use has to run code. | 02:13 | |
_grenzo | you're trying to turn the string 'use Moneys' into it's AST representation? | ||
[Coke] | try 'use Test' instead, that one's built in | 02:14 | |
m: dd "use Test".AST | 02:15 | ||
camelia | use Test | ||
[Coke] | m: say "use Test".AST | ||
camelia | RakuAST::StatementList.new( RakuAST::Statement::Use.new( module-name => RakuAST::Name.from-identifier("Test") ) ) |
||
[Coke] | (sorry, dd not as helpful with AST) | 02:16 | |
aruniecrisps | Hmmm, well in that case it looks like it's got error handling built in then | ||
02:19
hulk joined
02:21
kylese left
02:27
gabiruh left
02:33
_________ left
02:43
gabiruh joined
03:04
jpn joined
03:08
jpn left
03:15
hulk left,
kylese joined
03:16
gabiruh left
03:24
merp left
03:33
gabiruh joined
03:43
gabiruh left
03:56
merp joined
04:00
gabiruh joined
04:02
japhb left
04:05
jpn joined
04:10
jpn left
04:13
japhb joined
04:42
jpn joined
04:47
jpn left
05:20
TieUpYourCamel left,
Aedil left,
nativecallable6 left,
benchable6 left,
bisectable6 left,
coverable6 left,
clarkema_ left,
patrickb left,
atweedie left,
vrurg left
05:21
ingy left,
sdfgsdfg left,
GreaseMonkey left,
ab5tract left,
BinGOs left,
Opus left,
mst left,
zostay left,
rjbs left,
irth left
05:22
ingy joined,
sdfgsdfg joined,
GreaseMonkey joined,
ab5tract joined,
BinGOs joined,
Opus joined,
mst joined,
zostay joined,
rjbs joined,
irth joined,
TieUpYourCamel joined,
Aedil joined,
nativecallable6 joined,
benchable6 joined,
coverable6 joined,
bisectable6 joined,
clarkema_ joined,
patrickb joined,
atweedie joined,
vrurg joined
05:23
clarkema_ left
05:24
xinming left,
oodani left,
eseyman left,
Sevalecan left,
eof left,
gugod left,
bdju left,
jcallen left,
samebchase left,
tonyo left,
tbrowder__ left,
thebb left,
corwin left,
PotatoGim left,
discord-raku-bot left,
rba left,
mort left,
hvxgr left,
dpk left,
skaji_ left,
tib_ left,
acidsys left,
SmokeMachine left,
patrickb left,
atweedie left,
xinming joined,
oodani joined,
eseyman joined,
Sevalecan joined,
eof joined,
gugod joined,
bdju joined,
jcallen joined,
samebchase joined,
tonyo joined,
tbrowder__ joined,
thebb joined,
corwin joined,
PotatoGim joined,
discord-raku-bot joined,
rba joined,
mort joined,
hvxgr joined,
acidsys joined,
dpk joined,
skaji_ joined,
tib_ joined,
SmokeMachine joined,
atweedie joined,
samebchase left,
bdju left,
clarkema_ joined,
patrickb joined
05:25
bdju joined,
samebchase joined
05:28
tinita left,
hexology left,
gordonfish left,
jast left,
lizmat left,
leedo left,
tobs left,
esh left,
synthmeat left,
teatime left,
ecocode_ left,
kaskal- left,
tejr left,
maylay left,
Tirifto left,
nine left,
cm left,
kawaii left,
destroycomputers left,
pierrot left,
epony left,
tjr left,
sjn left,
kst left,
bloatable6 left,
tellable6 left,
quotable6 left,
notable6 left,
releasable6 left,
shareable6 left,
unicodable6 left,
evalable6 left,
committable6 left,
linkable6 left,
zups left,
dutchie left,
bd3i left,
andinus left,
tailgate left,
teatime joined,
ecocode_ joined,
kaskal- joined,
tejr joined,
maylay joined,
Tirifto joined,
nine joined,
cm joined,
kawaii joined,
destroycomputers joined,
pierrot joined,
japhb left,
kylese left,
dustinm` left,
simcop2387 left,
peder left,
Util left,
elcaro_ left
05:29
tejr left,
tejr joined
05:31
japhb joined,
kylese joined,
dustinm` joined,
simcop2387 joined,
peder joined,
Util joined,
elcaro_ joined,
epony joined,
tjr joined,
sjn joined,
kst joined,
bloatable6 joined,
tellable6 joined,
quotable6 joined,
notable6 joined,
shareable6 joined,
releasable6 joined,
unicodable6 joined,
evalable6 joined,
committable6 joined,
linkable6 joined,
zups joined,
dutchie joined,
bd3i joined,
andinus joined,
tailgate joined,
tinita joined,
hexology joined,
gordonfish joined,
jast joined,
lizmat joined,
leedo joined,
tobs joined,
esh joined,
synthmeat joined
05:33
tjr left,
epony left
05:34
epony joined,
HobGoblin left,
camelia left,
perlbot left,
avuserow left,
nebuchadnezzar left
05:35
tjr joined
05:36
HobGoblin joined,
camelia joined,
perlbot joined,
avuserow joined,
nebuchadnezzar joined
05:39
jpn joined
05:42
tinita left,
hexology left,
gordonfish left,
jast left,
lizmat left,
leedo left,
tobs left,
esh left,
synthmeat left,
epony left,
tjr left,
sjn left,
kst left,
bloatable6 left,
tellable6 left,
quotable6 left,
notable6 left,
releasable6 left,
shareable6 left,
unicodable6 left,
evalable6 left,
committable6 left,
linkable6 left,
zups left,
dutchie left,
bd3i left,
andinus left,
tailgate left,
japhb left,
kylese left,
dustinm` left,
simcop2387 left,
peder left,
Util left,
elcaro_ left,
teatime left,
ecocode_ left,
kaskal- left,
maylay left,
Tirifto left,
nine left,
cm left,
kawaii left,
destroycomputers left,
pierrot left,
discord-raku-bot left,
rba left,
mort left,
hvxgr left,
dpk left,
skaji_ left,
tib_ left,
acidsys left,
SmokeMachine left,
xinming left,
oodani left,
eseyman left,
Sevalecan left,
eof left,
gugod left,
jcallen left,
tonyo left,
tbrowder__ left,
thebb left,
corwin left,
PotatoGim left,
ingy left,
sdfgsdfg left,
GreaseMonkey left,
ab5tract left,
BinGOs left,
Opus left,
mst left,
zostay left,
rjbs left,
irth left,
TieUpYourCamel left,
Aedil left,
nativecallable6 left,
benchable6 left,
bisectable6 left,
coverable6 left,
vrurg left,
tejr left,
Sgeo left,
kjp left,
dano left,
itaipu left,
dead1 left,
gfldex left,
lucerne left,
jpn left,
bdju left,
justache left,
greppable6 left,
sourceable6 left,
silug left,
rypervenche left,
Geth left,
timo left,
jdv left,
phogg left,
avar left,
cleo left,
slu left,
DarthGandalf left,
tadzik left,
sivoais left,
mark22k left,
jrjsmrtn left,
bartolin left,
ACfromTX left,
Ekho left,
tbrowder_ left,
leont left,
xkr47 left,
samebchase left,
clarkema_ left,
patrickb left,
atweedie left,
gabiruh left,
El_Che left,
human-blip left,
Altreus left,
ilogger2 left,
jmcgnh left,
meooow left,
[Coke] left
05:43
samcv left,
broquaint left,
nicole left,
jpn joined,
tjr joined,
epony joined,
synthmeat joined,
esh joined,
tobs joined,
leedo joined,
lizmat joined,
jast joined,
gordonfish joined,
hexology joined,
tinita joined,
tailgate joined,
andinus joined,
bd3i joined,
dutchie joined,
zups joined,
linkable6 joined,
committable6 joined,
evalable6 joined,
unicodable6 joined,
releasable6 joined,
shareable6 joined,
notable6 joined,
quotable6 joined,
tellable6 joined,
bloatable6 joined,
kst joined,
sjn joined,
elcaro_ joined,
Util joined,
peder joined,
simcop2387 joined,
dustinm` joined,
kylese joined,
SmokeMachine joined,
tib_ joined,
skaji_ joined,
dpk joined,
acidsys joined,
hvxgr joined,
mort joined,
rba joined,
discord-raku-bot joined,
PotatoGim joined,
corwin joined,
thebb joined,
tbrowder__ joined,
tonyo joined,
jcallen joined,
gugod joined,
eof joined,
Sevalecan joined,
eseyman joined,
oodani joined,
xinming joined,
vrurg joined,
bisectable6 joined,
coverable6 joined,
benchable6 joined,
nativecallable6 joined,
Aedil joined,
TieUpYourCamel joined,
irth joined,
rjbs joined,
zostay joined,
mst joined,
Opus joined,
BinGOs joined,
ab5tract joined,
GreaseMonkey joined,
sdfgsdfg joined,
ingy joined,
gabiruh joined,
Sgeo joined,
kjp joined,
El_Che joined,
dano joined,
itaipu joined,
DarthGandalf joined,
dead1 joined,
gfldex joined,
human-blip joined,
lucerne joined,
justache joined,
tadzik joined,
Altreus joined,
ilogger2 joined,
sivoais joined,
mark22k joined,
greppable6 joined,
sourceable6 joined,
silug joined,
jmcgnh joined,
rypervenche joined,
Geth joined,
jrjsmrtn joined,
timo joined,
bartolin joined,
meooow joined,
[Coke] joined,
ACfromTX joined,
Ekho joined,
jdv joined,
tbrowder_ joined,
leont joined,
samcv joined,
slu joined,
cleo joined,
avar joined,
phogg joined,
xkr47 joined,
nicole joined,
broquaint joined
05:44
jpn left,
epony left
05:45
epony joined
05:56
merp left,
sftp left,
mtj left,
clarkema left,
jjatria left,
lucs left,
leah2 left
06:01
merp joined,
sftp joined,
mtj joined,
clarkema joined,
jjatria joined,
lucs joined,
leah2 joined
06:14
CIAvash joined
07:08
jpn joined
07:13
jpn left
07:35
jpn joined
07:41
jpn left
08:12
atweedie joined,
clarkema_ joined,
patrickb joined
08:13
atweedie left
08:14
clarkema_ left,
patrickb left
08:20
atweedie joined,
patrickb joined,
clarkema_ joined
08:36
CIAvash left
08:37
Sgeo left
09:16
dakkar joined
09:19
sena_kun joined
09:28
synthmeat left
09:30
synthmeat joined
09:31
epony left
09:37
epony joined
10:20
jpn joined
10:47
jpn left
|
|||
lizmat | aruniecrisps because a "use" statement can change the grammar, and thus parsing of code, the module *is* actually loaded at compile time | 10:50 | |
and if it cannot, then will fail | |||
m: use v6.e.PREVIEW; say RakuAST::Statement::Use.new(module-name => RakuAST::Name.from-identifier("Bar")) | 10:52 | ||
camelia | RakuAST::Statement::Use.new( module-name => RakuAST::Name.from-identifier("Bar") ) |
||
lizmat | aruniecrisps this does not happen if you programmatically create the AST for a "use Bar" | ||
m: use v6.e.PREVIEW; say RakuAST::Statement::Use.new(module-name => RakuAST::Name.from-identifier("Bar")).EVAL | 10:53 | ||
camelia | Could not find Bar in: /home/camelia/.raku /home/camelia/rakudo-m-inst-1/share/perl6/site /home/camelia/rakudo-m-inst-1/share/perl6/vendor /home/camelia/rakudo-m-inst-1/share/perl6/core CompUnit::Repository::AbsolutePath<… |
||
lizmat | unless you .EVAL it of course, and the module can not be foud | ||
*found | |||
10:57
jpn joined
11:02
jpn left
11:40
jpn joined
11:45
jpn left
12:05
jpn joined
|
|||
tbrowder__ | lizmat: any thoughts on feasability of autochecking for allowable subroutine named args? | 12:08 | |
sub f(:$bar --> Hash | bar) is export {..} | 12:11 | ||
lizmat | tbrowder__: not sure I follow | 12:12 | |
12:14
jpn left
|
|||
tbrowder__ | in tha sub i'm defining the allowable named args. if a caller uses anything else it would cause an exception. | 12:14 | |
lizmat | m: sub a(:$a, :$b) { }; a(:c) | ||
camelia | Unexpected named argument 'c' passed in sub a at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
lizmat | it's only on methods that unexpected named arguments are slurped into %_ | 12:15 | |
tbrowder__ | funny but in my code i swear i see named args a didn't expect being ignored | 12:16 | |
lizmat | m: my method a() { }; dd &a.signature # note that the sigature of a method always has an implicit *%_ | ||
camelia | :(Mu: *%_) | ||
lizmat | m: my sub a() { }; dd &a.signature # as opposed to subs | 12:17 | |
camelia | :() | ||
tbrowder__ | i'll keep an eye out | ||
lizmat | should only happen with methods, not subs | ||
unless the sub as an explicit *%_ in its signature | |||
*has | |||
12:19
jpn joined
|
|||
tbrowder__ | so subs was my prob, unexpected named arg being ignore. so, for my simple mind, what is the solution? | 12:19 | |
lizmat | provide a piece of code that shows the problem, so we can fix it ? | ||
tbrowder__ | ok, will do, thanks | 12:20 | |
lizmat | specifically an --ll-exception stack trace | ||
tbrowder__ | ah, my bad, it was a method. that's been around a while. i remember it haunting me a few years back. | 12:34 | |
lizmat | *phew* :-) | 12:35 | |
the only way to disallow unexpected nameds in a method is to do something like: die "unexpected nameds: %_.keys()" if %_; | 12:36 | ||
tbrowder__ | so in a method i think you got me to check that % to see if was empty or something. does that sound right? | ||
lizmat | yes :-) but %_ rather than % :-) | 12:37 | |
tbrowder__ | cool, thank you!! | ||
12:37
jpn left
|
|||
Voldenet | if you need this kind of behavior better is to use a subroutine instead | 13:02 | |
m: class :: { x() { } }.x(:thing); | 13:03 | ||
camelia | ===SORRY!=== Error while compiling <tmp> Unexpected block in infix position (missing statement control word before the expression?) at <tmp>:1 ------> class :: { x()⏏ { } }.x(:thing); expecting any of: infix … |
||
Voldenet | m: class :: { method x() { } }.x(:thing); | ||
camelia | ( no output ) | ||
Voldenet | m: sub x { }; class :: { }.&x(:thing); | ||
camelia | Too many positionals passed; expected 0 arguments but got 1 in sub x at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
Voldenet | m: sub x { }; class :: { }.&x(); | ||
camelia | Too many positionals passed; expected 0 arguments but got 1 in sub x at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
Voldenet | m: class X { method x() { } }; sub x(X $x){}; X.&x(); | 13:04 | |
camelia | ( no output ) | ||
Voldenet | m: class X { method x() { } }; sub x(X $x){}; X.&x(:y); | 13:05 | |
camelia | Unexpected named argument 'y' passed in sub x at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
tbrowder__ | Voldenet: good point, but my use case is a bit different. It can very likely be designed better, but that's where I am for now. | 13:09 | |
Voldenet | I wish methods didn't accept arbitrary named arguments | 13:11 | |
tbrowder__ | i try to get design help here when i can, but too often jump in without that life preserver | ||
Voldenet | consider StrictNamedArguments package | 13:13 | |
tbrowder__ | i also, but i think that has to be because of some Rake internal magic that requires it. | ||
i will do that. | |||
Voldenet | it's runtime exception, but better than nothing | 13:14 | |
13:14
tadzik left,
tadzik joined
|
|||
tbrowder__ | wow, looks pretty slick. so, if i understand correctly, all i have to do use yr pkg and in my class add trait "is strict" to all my added methods? | 13:24 | |
lizmat | It's El_Che's package, actually | 13:25 | |
but the approach comes at a price, an extra layer of indirection :-( | |||
the proper approach would be to *not* install the slurpy *%_ in the signature of the method | 13:26 | ||
tried that years ago, and it would fail somewhere deep in the bowels, because the core assumes there's a *%_ in the signature of each method | 13:27 | ||
maybe I should revisit that approach :-) | |||
or someone else should :-) | |||
tbrowder__ | oops, a tip of the hat to nxadm aka El_Che | ||
lizmat: that would surely ease signature documentation! i get lost in that cave | 13:31 | ||
and i | |||
and in enums. although i got practical enums tamed a little more in my update to the Date::Event pkg | 13:33 | ||
13:34
jpn joined
13:39
jpn left
13:41
epony left
13:55
itaipu left
13:56
epony joined
|
|||
librasteve | Voldenet: I was interested in your point about named args and looked up the rationale for this from the design docs... | 13:59 | |
=head1 Interface Consistency By default, all methods and submethods that do not declare an explicit C<*%> parameter will get an implicit C<*%_> parameter declared for them whether they like it or not. In other words, all methods allow unexpected named arguments, so that C<nextsame> semantics work consistently. If you mark a class "C<is hidden>", it hides the current class from "C<nextsame>" semantics, and | |||
incidentally suppresses the autogeneration of C<*%_> parameters. Methods on hidden classes may still be called as C<$obj.NameOfHiddenClass::yourmethod>. A similar effect can be achieved from the derived class by saying C<hides Base> instead of C<is Base>. | |||
github.com/Raku/old-design-docs/bl...bjects.pod L:2264 | 14:00 | ||
anyway it seems that the consistency of nextsame is to blame (I guess to chain args through) ... this kinda makes sense to me as a design trade off (and has ways to turn off the behaviour such as 'is hidden' which I never came across before). so you may not like this particular design choice ... but it wasn't just arbitrary | 14:02 | ||
Voldenet | Huh | ||
m: class :: { }.&x(:thing); | |||
camelia | ===SORRY!=== Error while compiling <tmp> Undeclared routine: x used at line 1 |
||
Voldenet | m: class :: { method x() { } }.x(:thing); | 14:03 | |
camelia | ( no output ) | ||
Voldenet | m: class :: is hidden { method x() { } }.x(:thing); | ||
camelia | Unexpected named argument 'thing' passed in method x at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
Voldenet | That is useful to know | ||
librasteve | yeah I was surprised that 'is hidden' and 'hides' made it to the implementaiton (and the docs too!) | ||
lizmat | looks like "is hidden" is not really documented :-( | 14:10 | |
14:29
jpn joined
14:34
jpn left
14:38
jgaz joined
14:50
jpn joined
14:59
_________ joined
|
|||
librasteve | well its documented a bit docs.raku.org/routine/hides (but not searchable) tbh this is kind of a master class feature | 15:09 | |
lizmat | in any case, the different method signatures appear to be a side-effect | 15:12 | |
librasteve | of the despatch semantics? | 15:13 | |
15:14
Sgeo joined
|
|||
Voldenet | Implicit *%_ is the implementation detail of nextsame, when you throw in "hidden/hides" to the mix it becomes weird | 15:32 | |
m: class A is hidden { method x(:$p) { say $p } }; class B is A { method x() { say "foo"; nextsame } }.x(:p); | |||
camelia | foo | ||
Voldenet | m: class A { method x(:$p) { say $p } }; class B hides A { method x() { say "foo"; nextsame } }.x(:p); | ||
camelia | foo | ||
Voldenet | m: class A { method x(:$p) { say $p } }; class B is A { method x() { say "foo"; nextsame } }.x(:p); | ||
camelia | foo True |
||
Voldenet | oh, and | 15:35 | |
m: class A { method x(:$p) { say $p } }; class B is A is hidden { method x() { say "foo"; nextsame } }.x(:p); | |||
camelia | Unexpected named argument 'p' passed in method x at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
15:39
derpydoo joined
|
|||
librasteve | weird? yes! ... to be fair it does what is says on the tin (although I would be a bit upset to see class B is A is hidden in production code!) ... I can imagine some use cases ... for example if you are refactoring together some "grandparent" classes from which you would like to inherit, but many of the method names conflict (or are externally provided or you cannot guarantee no conflict down the line) so you | 16:15 | |
want to mask them 100% ... but you want to use normal parent-child nextsame semantics in your stuff ... bit of a strech I know | |||
16:19
vlad joined
16:59
jpn left
|
|||
lizmat | another disadvantage is that "is hidden" affects *all* methods in the class | 17:30 | |
which may be too coarse-grained for you | 17:31 | ||
18:00
dakkar left
18:37
epony left
|
|||
SmokeMachine | just for curiosity, I've used the ChatGPT to generate a new Pod6 for may Configuration module based on the original one, and I think that did it very good: github.com/FCO/Configuration | 18:46 | |
lizmat | SmokeMachine: the boilerplate: use Configuration::Node; and does Configuration::Node | 18:50 | |
could also be handled by the EXPORT, by mixing in the Connfiguration::Node role into the given class | 18:51 | ||
the mixin would still be done at compile time | 18:52 | ||
SmokeMachine | but the clas does not necessarily need to does that role | ||
lizmat | "To define your application's configuration structure, create a Raku class that does the Configuration::Node role. This class will specify the fields and default values for your configuration." | 18:53 | |
SmokeMachine | I'm still deciding if it makes sense to change that... | ||
lizmat | appears to say otherwise ? | ||
SmokeMachine | Thanks, I'll change that | ||
It seems I was wrong... and the root class needs to be a Node... I think I'll follow your suggestion... | 18:55 | ||
antononcube | @SmokeMachine Did you use ChatGPT via Raku? | 19:08 | |
SmokeMachine | no... :( | ||
(but I was writing a module to play with with the assistent api at some point...) | 19:09 | ||
antononcube | The OpenAI's Assistant functionalities seem to "unfinished" at the moment. Same with their LLM functions. | 19:10 | |
Granted, they honestly say those are in Beta-stage. | |||
As for making Raku configurations using LLMs -- that can be done either via Raku LLM-functions or with a Question Answers System (QAS). | 19:12 | ||
Well, QAS, might be too involved. But definitely LLM examples based generation should applicable, | 19:13 | ||
SmokeMachine | When I was doing that my only intention was to play with that API... | 19:23 | |
antononcube | I understand. I tried out the assistant framework for work project using their Python package. | 19:24 | |
It is does not always work. Or, more precisely, it does not adhere to expectations. (Not just mine, also implied from the documentation.) | 19:25 | ||
SmokeMachine | lizmat: is it better now? github.com/FCO/Configuration | 19:50 | |
lizmat | much better, except the first example in the README still uses the old boilerplate ? | 19:53 | |
SmokeMachine | yes, but it explains you can avoid adding the role... | 19:54 | |
with the 2nd example | |||
make sense? | 19:55 | ||
lizmat | why would you need to add the role "manually" ever ? | 19:58 | |
antononcube | @SmokeMachine I think you should spell out a few use cases in the "Configuration" README. | ||
lizmat | that feels like an exception to me | ||
SmokeMachine | if you are going to have more than one layer you may need to `use` that... for example: github.com/FCO/Configuration/blob/...ig.rakumod | 19:59 | |
lizmat | I'm not sure I follow | 20:01 | |
SmokeMachine | antononcube: I think that's a great idea... but I confess I'm failing to think into some examples | ||
lizmat: I think you are right... (again) | |||
lizmat | ak& | 20:03 | |
20:05
vlad left
|
|||
SmokeMachine | antononcube: do you have any idea? | 20:07 | |
antononcube | @SmokeMachine I was thinking configurations of LLMs. | 20:22 | |
@SmokeMachine See the LLM configurations here: raku.land/zef:antononcube/LLM::Fun...igurations | 20:23 | ||
@SmokeMachine But I might be misunderstanding what "Configuration" is about. Is it about setting up attributes in data classes / objects? Why not just use hash maps? | 20:33 | ||
SmokeMachine | antononcube: because Configuration creates builders that can type check your configuration while you are writing it and returns to your program an immutable (if you defined your config class that way). And it also can return to your program a Supply that emits new configuration objects every time the configuration changes | 20:39 | |
20:40
jpn joined
|
|||
SmokeMachine | it makes it impossible to someone have invisible typos on configuration files and also makes it programable, so, you can for example have loops to define many attributes... | 20:41 | |
antononcube: for example, here we have an example of a program using cro and Configuration to configure host and port for the cro server. if that's running and the configuration file changes, it automaticaly restart the cro server with the new port: github.com/FCO/Configuration/tree/...amples/cro | 20:46 | ||
make sense? | 20:48 | ||
21:05
jpn left
21:10
eseyman left
21:15
eseyman joined
21:39
discord-raku-bot left
21:40
discord-raku-bot joined
|
|||
antononcube | @SmokeMachine I will study the example tonight. | 21:50 | |
21:53
dano left
22:01
itaipu joined
22:11
dano joined
22:23
jgaz left
|
|||
SmokeMachine | antononcube: please, let me know your thoughts/suggestions | 22:41 | |
23:12
epony joined
23:24
sena_kun left
23:36
derpydoo left
|