objectionary
A new value is not saved by cage
+package preface
+alias cage org.eolang.cage
+junit
[] > test
[init] > mycage
[value] > wrapper
cage (wrapper init) > value
[new-value] > write
value.write (wrapper new-value) > @
value.value > @
mycage 0 > c
seq > @
c
c.write 1
c.eq 1
@dours What is the result of dataization? Is the snippet above valid? I don't get what would be the result of dataization for:
[value] > wrapper
It has no @.
@mximp The snippet above is written as an EO test. So, a result of dataization of the whole snippet should be boolean TRUE. It is in fact boolean FALSE. Which means that the snippet is dataizable, though the result is incorrect (IMHO).
The wrapper object is not dataizable. But it is never dataized. It is used as a trivial container for other objects. For integers in this case. An integer is wrapped into wrapper and saved into cage by mycage object. It is explicitly extracted from the wrapper each time it is used in this line value.value > @ of the mycage object.
If we remove first statement in seq the snippet works fine.
It also works fine if replace wrapper with plain data.
It is still not clear why it fails. Need to add more logging to understand what's happening inside.
After further analysis - the issue is in internal caching. In the initial example after first c within seq the c.@ is calculated which becomes mycage.@=value.value=0. And it's cached.
Next time we try to calculate c.eq it will pick 0.eq regardless of previous c.write 1.
If we change @ to some custom attribute the code works as expected:
[] > test
[init] > mycage
[value] > wrapper
cage (wrapper init) > value
[new-value] > write
value.write (wrapper new-value) > @
value.value > res
mycage 0 > c
seq > @
c
c.write 1
c.res.eq 1
It also work well if we try to access value directly:
[] > test
[init] > mycage
[value] > wrapper
cage (wrapper init) > value
[new-value] > write
value.write (wrapper new-value) > @
value.value > @
mycage 0 > c
seq > @
c
c.write 1
c.value.value.eq 1
@yegor256 is caching for @ attribute is somewhat designed initially? Is my logic correct here or I'm missing something?
@mximp you are right. We have a special annotation @Volatile in the runtime, which is attached to EOcage: https://github.com/objectionary/eo/blob/0.28.7/eo-runtime/src/main/java/EOorg/EOeolang/EOcage.java#L44 Thanks to this annotation, cage is "volatile" and doesn't have this @-caching logic. However, if we decorate cage, this new object is not volatile anymore.
@dours So this behaviour is by design. Is it clear how to workaround the issue?