Closed hoschi closed 7 years ago
That sucks! Sorry for the bug. Please, allow me 12 hours to fix and publish it.
The fix should be trivial. Each method is stored as a reference. Meaning that:
const Base = Collision.collisionProtectAnyMethod().methods({ getName() { return 'name'; } });
const Stamp1 = Base.props().methods();
const Stamp2 = Base.props().methods();
const Final = stampit(Stamp1, Stamp2); // THIS MUST NOT THROW
So:
Stamp1.compose.methods.getName
should be ===
to the Stamp2.compose.methods.getName
.
This line should be fixed: https://github.com/stampit-org/stamp/blob/ce12385169ccd70d1b021421d974805143eb6c66/packages/collision/index.js#L41
The fix should be trivial.
niiiice, I hoped to hear that :+1:
Please, allow me 12 hours to fix and publish it.
Awesome! I would then test it on Monday and report back fast.
Published as @stamp/collision@0.2.5
Thanks, I think I can do the update this week
works! :1st_place_medal:
I try to use the new stamp/it module which works got so far, but I found another problem with collision detection :(
DefaultStamp, used for every new stamp which doesn't compose with another already existing stamp:
test
which fails with:
I see why it happens, in the last line I use two stamps which both have
getName
. I can solve this usingNamed
stamp inRobotimal
and not the other stamps.My Problem here is that at the moment when I write
Robot
and not thinking aboutRobotimal
I need to useNamed
soRobot
is fully functional. Months later when I realize I need aRobotimal
I need to refactor all stamps I use for the new stamp.Is it possible to identity check the stamp
getName
came from and see that it is the same stamp (Named
) and don't declare it as collision? Because it doesn't override the existing behavior at all.