00:11 arkiuat joined 00:18 librasteve_ left 00:39 [Coke] left 01:28 arkiuat left 01:29 arkiuat joined 01:59 arkiuat left 02:01 sibl joined 02:10 hulk joined, kylese left 02:21 arkiuat joined 02:27 arkiuat left 02:32 [Coke] joined 02:38 sibl left 02:44 sibl joined 02:56 arkiuat joined 03:05 sibl left 03:06 sibl joined 03:15 hulk left, kylese joined 03:23 sibl left 03:27 arkiuat left 03:30 sibl joined 03:31 arkiuat joined 03:36 arkiuat left 04:03 arkiuat joined 04:08 arkiuat left 04:10 annamalai joined, arkiuat joined 04:17 sibl left 04:19 sibl joined 05:22 arkiuat left 05:40 Aedil joined 06:45 sibl left, sibl joined 07:10 Sgeo left 07:11 abraxxa joined 07:16 abraxxa left 07:17 abraxxa joined 07:50 sibl left 07:54 sibl joined 07:55 sibl left 08:23 sibl joined 08:53 dakkar joined 10:34 librasteve_ joined 11:41 sibl left 11:56 sibl joined 12:04 sibl left 12:05 sibl joined 12:23 sibl left 12:50 sibl joined 13:09 sibl left, sibl joined 13:18 sibl left 13:24 sibl joined 13:29 sibl left 14:21 Aedil left 16:17 abraxxa left 17:39 dakkar left
SmokeMachine m: role A { submethod TWEAK(:@events, |) {say "aaa"; self.apply: $_ for @events} }; class B does A { has $.value = 0; method apply($i) { $!value += $i } }; say B.new: :events[1,2], :5value # this seems to work 18:07
camelia aaa
B.new(value => 8)
SmokeMachine but this seems to not work:
m: class A { submethod TWEAK(:@events, |) {say "aaa"; self.apply: $_ for @events} }; class B is A { has $.value = 0; method apply($i) { $!value += $i } }; say B.new: :events[1,2], :5value
camelia aaa
B.new(value => 5)
SmokeMachine why? Shouldn't that work? 18:08
it seems it have run the events: 18:10
m: class A { submethod TWEAK(:@events, |) {say "aaa"; self.apply: $_ for @events; say self} }; class B is A { has $.value = 0; submethod TWEAK (|) {say "bbb"}; method apply($i) { $!value += $i } }; say B.new: :events[1,2], :5value
camelia aaa
B.new(value => 3)
bbb
B.new(value => 5)
SmokeMachine it seems to be the same obj... 18:11
m: class A { submethod TWEAK(:@events, |) {say "aaa: {self.WHERE}"; self.apply: $_ for @events; say self} }; class B is A { has $.value = 0; submethod TWEAK (|) {say "bbb: {self.WHERE}"}; method apply($i) { $!value += $i } }; say B.new: :events[1,2], :5value
camelia aaa: 4905413393872
B.new(value => 3)
bbb: 4905413393872
B.new(value => 5)
SmokeMachine oh... the assignment is happenning after the sum... 18:12
is there a way to make it work? 18:13
ab5tract submethods are not part of the inheritance chain 18:36
If you put some reporting inside of apply, I expect that you will find that it is never run 18:37
Even if TWEAK were inherited, you would be overriding it in B 18:38
SmokeMachine: unless I’m misunderstanding something? 18:39
SmokeMachine But it should (and do) call all TWEAKs on the inheritance chain… 18:43
m: class A { submethod TWEAK(:@events, |) {say "aaa: {self.WHERE}"; self.apply: $_ for @events; say self} }; class B is A { has $.value = 0; submethod TWEAK (|) {say "bbb: {self.WHERE}"}; method apply($i) { say “apply: $i”; $!value += $i } }; say B.new: :events[1,2], :5value 18:45
camelia aaa: 3623197818208
apply: 1
apply: 2
B.new(value => 3)
bbb: 3623179599160
B.new(value => 5)
SmokeMachine ab5tract: it does call apply… 18:47
docs.raku.org/syntax/TWEAK
ab5tract Ah, I guess I had it backwards 18:48
That’s actually quite clear from your example. I was hallucinating an A.new 18:49
SmokeMachine m: class A { submethod TWEAK(:@events, |) {say "aaa: {self.WHERE}"; self.apply: $_ for @events; say self} }; class B is A { has $.value = 0; submethod TWEAK (|) {say "bbb: {self.WHERE}"}; method apply($i) { say “apply: $i”; $!value += $i } }; say B.new: :5value, :events[1,2] 18:51
camelia aaa: 3872238749512
apply: 1
apply: 2
B.new(value => 3)
bbb: 3872156218680
B.new(value => 5)		 18:52
ab5tract Try making apply a submethod?
“Since submethods are not inherited, an interesting use case is precisely methods that are going to be called from the standard submethods such as BUILD or TWEAK.”
docs.raku.org/type/Submethod
SmokeMachine m: class A { submethod TWEAK(:@events, |) {say "aaa: {self.WHERE}"; self.apply: $_ for @events; say self} }; class B is A { has $.value = 0; submethod TWEAK (|) {say "bbb: {self.WHERE}"}; submethod apply($i) { say “apply: $i”; $!value += $i } }; say B.new: :5value, :events[1,2]
camelia aaa: 3631116785232
apply: 1
apply: 2
B.new(value => 3)
bbb: 3631098508600
B.new(value => 5)
ab5tract So I had the “not inherited” in mind, but that doesn’t mean what I thought it did 18:53
SmokeMachine Same… :( (sorry for testing it here… but my daughter “stole” my computer to do her homework)
ab5tract You can always msg camelia:) 18:55
But it’s not a problem to work out a confusion here either
SmokeMachine Thanks for reminding me that
ab5tract apparently doesn’t do much complexity inheritance wise 18:56
SmokeMachine I think it’s overriding the value… if I delay the apply calls, it seems to “work”… 19:04
m: class A { submethod TWEAK(:@events, |) {say "aaa: {self.WHERE}"; start { self.apply: $_ for @events; say self} } }; class B is A { has $.value = 0; submethod TWEAK (|) {say "bbb: {self.WHERE}"}; method apply($i) { say “apply: $i”; $!value += $i } }; say B.new: :5value, :events[1,2]
camelia aaa: 2595291649824
bbb: 2595167091848
B.new(value => 5)
SmokeMachine m: class A { submethod TWEAK(:@events, |) {say "aaa: {self.WHERE}"; start { await Promise.in: 1; self.apply: $_ for @events; say self} } }; class B is A { has $.value = 0; submethod TWEAK (|) {say "bbb: {self.WHERE}"}; method apply($i) { say “apply: $i”; $!value += $i } }; say B.new: :5value, :events[1,2]
camelia aaa: 5018267118752
bbb: 5018267118752
B.new(value => 5)
SmokeMachine (It did work when I asked Camélia…) 19:05
ab5tract Makes sense that it would be somewhat fiddly, since it’s a promise that isn’t awaited (the outermost one)
timo wait where did promises come from now %) 19:08
there it is, well hidden 19:09
ab5tract m: class A { has $.value is rw = 0;submethod TWEAK(:@events, |) {say "aaa: {self.WHERE}"; self.apply: $_ for @events; say self} }; class B is A { submethod TWEAK (|) {say "bbb: {self.WHERE}"}; method apply($i) { say “apply: $i”; self.value += $i } }; say B.new: :5value, :events[1,2]
camelia aaa: 2964357146568
apply: 1
apply: 2
B.new(value => 8)
bbb: 2964232289184
B.new(value => 8)
timo my assumption is that when it's a subclass, it does the tweak for the parent class first (thereby adding $i to self.value each time) then it finishes the BUILD step for the derived class B, thereby setting self.value to the value you passed to method new
ab5tract I think it must be because A didn’t have a $!value 19:10
timo m: class A { submethod TWEAK(:@events, |) {say "aaa: {self.WHERE}"; self.apply: $_ for @events; say self} }; class B is A { has $.value = 0; submethod TWEAK (|) {say "bbb: {self.WHERE}"}; submethod apply($i) { say “apply: $i, $!value was”; $!value += $i; say "value applied, new value is $!value" } }; say B.new: :5value, :events[1,2];
camelia aaa: 5144264002552
Use of uninitialized value element of type Any in string context.
Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful.
apply: 1, was
value applied, new value is 1
apply: 2, 1 was
va…
timo right, it's also not got a default value at that point yet, for i suppose the same reason 19:11
SmokeMachine m: my $p; class A { submethod TWEAK(:@events, |) {say "aaa: {self.WHERE}"; $p = Promise.in(1).then: { self.apply: $_ for @events; say self} } }; class B is A { has $.value = 0; submethod TWEAK (|) {say "bbb: {self.WHERE}"}; method apply($i) { say “apply: $i”; $!value += $i } }; my $b =  B.new: :5value, :events[1,2]; await $p; say $b
camelia aaa: 6528921472464
bbb: 6528921472464
apply: 1
apply: 2
B.new(value => 8)
B.new(value => 8)
timo m: class A { submethod TWEAK(:@events, |) {say "aaa: {self.WHERE}"; self.apply: $_ for @events; say self} }; class B is A { has $.value = 0; submethod TWEAK (|) {say "bbb: {self.WHERE}"}; submethod apply($i) { say “apply($i) value: $!value.raku()”; $!value += $i; say "new value($!value.raku())" } }; say B.new: :5value, :events[1,2];
camelia aaa: 6554858797216
apply(1) value: Any
new value(1)
apply(2) value: 1
new value(3)
B.new(value => 3)
bbb: 6554858797216
B.new(value => 5)
timo m: class A { submethod TWEAK(:@events, |) {say "aaa: {self.WHERE}"; self.apply: $_ for @events; say self} }; class B is A { has $.value = 0; submethod TWEAK (|) {say "bbb: {self.WHERE}"}; submethod apply($i) { say “apply($i) value: $!value.raku()”; $!value += $i; say "new value($!value.raku())" } }; say B.new: :99value, :events[1,2]; 19:12
camelia aaa: 5082389657336
apply(1) value: Any
new value(1)
apply(2) value: 1
new value(3)
B.new(value => 3)
bbb: 5082389657336
B.new(value => 99)
timo the :99value wins because it happens last and it's just an assignment so it overwrites everything before it
SmokeMachine ab5tract: shouldn’t need $!value… should it? 19:16
timo I think, the moment that TWEAK is called, the object already exists mostly in its final state, so it does have a $!value, and calling .apply on self works out fine for that reason
ab5tract But A doesn’t have a $!value in the first example 19:17
It works when I added it
timo there's been too many camelia: messages for me to understand what "the first example" now refers to :D 19:18
19:18 Aedil joined
ab5tract Fair enough:) 19:18
timo oh there it is 19:19
ab5tract I got it to work by moving $.value to A and adding is rw
timo yes, I think that's because having the $.value in A means its initialisation happens earlier than the TWEAK call inside A
ab5tract I guess the question is whether all BUILD submethods are run before any TWEAKs
timo m: class A { has $.value = (say "getting default value of value!" || 99); submethod TWEAK { say "tweak inside A"; }; }; class B is A { submethod TWEAK { say "tweak in B" } }; say "first B:"; B.new(:99value); say "second B:"; B.new() 19:20
camelia first B:
tweak inside A
tweak in B
second B:
getting default value of value!
tweak inside A
tweak in B
timo m: class A { submethod TWEAK { say "tweak inside A"; }; }; class B is A { has $.value = (say "getting default value of value!" || 99); submethod TWEAK { say "tweak in B" } }; say "value inside B this time"; say "first B:"; B.new(:99value); say "second B:"; B.new() 19:21
camelia value inside B this time
first B:
tweak inside A
tweak in B
second B:
tweak inside A
getting default value of value!
tweak in B
timo there I think that shows the exact situation
well, I had to make it say something inside the default value in order for it to give an output at the right moment
I guess a "where" clause would have worked
ab5tract that works well enough I think 19:22
timo m: class A { submethod TWEAK { say "tweak inside A"; }; }; class B is A { has $.value where *.say = 99; submethod TWEAK { say "tweak in B" } }; say "check phaser, value inside B this time"; say "first B:"; B.new(:99value); say "second B:"; B.new()
camelia 99
check phaser, value inside B this time
first B:
tweak inside A
99
tweak in B
second B:
tweak inside A
99
tweak in B
timo m: class A { has $.value where *.say = 99; submethod TWEAK { say "tweak inside A"; }; }; class B is A { submethod TWEAK { say "tweak in B" } }; say "check phaser, value inside A again"; say "first B:"; B.new(:99value); say "second B:"; B.new() 19:23
camelia 99
check phaser, value inside A again
first B:
99
tweak inside A
tweak in B
second B:
99
tweak inside A
tweak in B
timo ^- the very first "99" in the output is probably the optimizer checking if 99 can be a valid default value for $.value and calling its WHERE function
ab5tract SmokeMachine: does it make sense? 19:26
timo not sure if there's a "phaser" that's more appropriate in terms of where in the build process it happens 19:27
SmokeMachine Yes, it does… but it does not solve my case… :( I think I’ll have to find a different way… 19:39
19:40 annamalai left 20:19 librasteve_ left 21:25 justache left 21:28 justache joined 21:41 Aedil left 23:21 Sgeo joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!