3 ms·
I guess in Raku you would create a Boat role, and you would create a clone of a House instance with the Boat role mixed in, when needed. In Raku speak: my
by lizmat 5y ago
I guess in Raku you would create a Boat role, and you would create a clone of a House instance with the Boat role mixed in, when needed.
In Raku speak:
my $house = House.new;
my $houseboat = $house but Boat;
See: https://docs.raku.org/routine/but https://docs.raku.org/routine/but
There would be no need to de-compose.
- fenomas 5y agoBut note that the point of an ECS is being able to dynamically change roles without recreating new entities. If changing a house into a houseboat means creating a new entity, then everyone who had a reference to the house would need to be informed of the new reference.
- lizmat 5y agoDoesn't de-composing have the same issue, though?
- fenomas 5y agoI'm not sure I follow. In ECSs that I'm familiar with, entities are integer IDs, not class objects. So adding or removing components (roles) to an entity doesn't make use of any language-level features, it's just calls to the ECS library. E.g. in JS: var id = ecs.createEntity() // returns an int ecs.addComponent(id, 'house') ecs.addComponent(id, 'boat') So, very different from the class-based approach being floated a few comments ago. Does that answer your question?
- raiph 5y agoLiz suggested `but`, but that creates a new entity with the role mixed in. Instead one can use `does` to mix in to an existing entity: role House {} role Boat {} my \id = 42; id does House; id does Boat; say id ~~ House; # True (What's missing is the ability to drop a mixin once it's been added via `does`.)