Closed maxonfjvipon closed 6 months ago
@yegor256 about these two places where we replaced \rho
: we replace it after we get()
the attribute through \phi
or \lambda
which seems a bit strange:
[] > animal
"Hello" > say
[] > cat
animal > @
cat.@.say.^ # refers to animal
cat.say.^ # refers to cat because we replaced \rho
cat.@.say.^ # now refers to cat because we replaced \rho above
Correct me if I'm wrong
UPD: this test confirms it:
static class Animal extends PhDefault {
Animal() {
super(Phi.Φ);
this.add("say", new AtOnce(new AtComposite(this, rho -> {
Phi phi = new Data.ToPhi("Hello");
phi.attr("ρ").put(rho);
return phi;
})));
}
}
static class Cat extends PhDefault {
Cat(Phi animal) {
super(Phi.Φ);
this.add(Attr.PHI, new AtSimple(animal));
}
}
@Test
void other() {
Phi animal = new Animal();
Phi cat = new Cat(animal);
System.out.println("animal");
System.out.println(animal.hashCode());
System.out.println("animal.say.^");
System.out.println(animal.attr("say").get().attr("ρ").get().hashCode());
System.out.println("cat.@.say.^");
System.out.println(cat.attr(Attr.PHI).get().attr("say").get().attr("ρ").get().hashCode());
System.out.println("cat.say.^");
System.out.println(cat.attr("say").get().attr("ρ").get().hashCode());
System.out.println("cat.@.say.^");
System.out.println(cat.attr(Attr.PHI).get().attr("say").get().attr("ρ").get().hashCode());
}
The output is confusing:
This rule from phi paper shows that when we retrieve attribute from the object, we should make a copy of given object and change \rho
(copying is the part of application process):
Meantime this rule shows that when we retrieve attribute through \phi
, we should just retrieve it from the object attached to \phi.
Combination of this two rules shows that we have two problems in our current java implementation:
\rho
when we retrieve attribute through \phi
or \lambda
here and here\rho
to this
; which we're not doing.The only thing I'm not sure about: every attribute retrieval leads to creating new object:
int.plus > plus1
int.plus > plus2
These plus1
and plus2
are different objects. Is it okay?
@yegor256 WDYT?
@maxonfjvipon yes, they should be two different objects
@yegor256 I guess this rule should not be applied when \tau1
is \rho
or \sigma
?
Update:
Changing \rho
while dispatch is not working. Why:
[] > x
1.plus 2 > three
When x.three
will be dataized - new \rho
attached to x
is injected. But x.three
refers to 1.plus 2
which means that (1.plus 2).^
is changed. But int.plus
object uses \rho
for dataization. When it was 1
, 1.plus 2
worked, but when we changed it to x
, but does not work anymore, plus
lost information about original \rho
which was 1
.
When object is created for the first time (formatted) it should not have \rho
\rho
should be immutable. It should be set only once while application (copying) process. If we're trying to copy object with already set \rho
- it should not be changed
[delta] > int
[] > plus
int.^ # error, rho is absent
int 5 > int1 int1.^ # refers to global phi object
int1.plus.^ # refers to int1 int1' > int2 int2.plus.^ # refers to int1 int1.plus != int2.plus # different objects
@yegor256 please correct me, if I'm wrong
Given result:
\rho
when it's formed\rho
is immutable and set when object is dispatched (if \rho
was not set before). When attribute is dispatched through decoratee @
, the \rho
is set to the object, that starts retrieval.
[] > x
[] > @
[] > z # \rho is absent
[] > y # \rho is absent
x.y > xy # xy.^ -> x
x.z > xz # xz.^ -> x
@maxonfjvipon 4 puzzles #2978, #2979, #3067, #3068 are still not solved; solved: #2965, #2966, #2967, #2968, #2969, #2970, #2971, #2972, #2973, #2974, #2975, #2976, #2977, #2980, #2981, #2999, #3000, #3001, #3002, #3004, #3005, #3006, #3007, #3008, #3009, #3010, #3011, #3012, #3013, #3015, #3021, #3055.
@maxonfjvipon 3 puzzles #2978, #2979, #3067 are still not solved; solved: #2965, #2966, #2967, #2968, #2969, #2970, #2971, #2972, #2973, #2974, #2975, #2976, #2977, #2980, #2981, #2999, #3000, #3001, #3002, #3004, #3005, #3006, #3007, #3008, #3009, #3010, #3011, #3012, #3013, #3015, #3021, #3055, #3068.
@maxonfjvipon 2 puzzles #2979, #3067 are still not solved; solved: #2965, #2966, #2967, #2968, #2969, #2970, #2971, #2972, #2973, #2974, #2975, #2976, #2977, #2978, #2980, #2981, #2999, #3000, #3001, #3002, #3004, #3005, #3006, #3007, #3008, #3009, #3010, #3011, #3012, #3013, #3015, #3021, #3055, #3068.
@maxonfjvipon the puzzle #3067 is still not solved; solved: #2965, #2966, #2967, #2968, #2969, #2970, #2971, #2972, #2973, #2974, #2975, #2976, #2977, #2978, #2979, #2980, #2981, #2999, #3000, #3001, #3002, #3004, #3005, #3006, #3007, #3008, #3009, #3010, #3011, #3012, #3013, #3015, #3021, #3055, #3068.
We have a EO code:
I suppose that:
five.^
refer toscope
inner.^
refer toscope
applied.^
refer toscope
These all
\rho
's refer toscope
because all these objects are bound But what aboutapplied.x.^
. What it supposed to refer to? I think it should refer toapplied
, it seems logical to me, but I'm not sure. Anyway in current Java implementationapplied.x.^
does not refer toapplied
, it refers toscope
.This test passes:
@yegor256 WDYT?