player-03 / echoes Goto Github PK

There are some issues with abstract types

Do you use vscode with the Haxe compilation server mode? I had a lot of ramp up issues when using Echoes because macro issues would often get the server into a permanent broken state.

Now I trained myself to restart the Haxe compilation server whenever I see huge cryptic compiler errors :)

Just wanted to point this out in case anyone searches for the this. It's probably an issue in Haxe, but hard to repro. But maybe there are things this repo could do to avoid falling into those issues.

Sorry that I don't have a repro case right now.

When I compile a project and set the echoes_profiling flag, it gives a build error in
System.hx:193: characters 38-52 : Float should be Int

From the code:

public function getStatistics():SystemDetails {
		return {
			name: Std.string(this)
			#if echoes_profiling , deltaTime: __updateTime__ #end
		};
}

It looks like __updateTime__ is a Float while deltaTime is an Int

This framework was designed and implemented by deepcake, and is now maintained by player-03.

This sentence makes me think that https://github.com/deepcake/echo is no longer maintained. Is this really true? Can we add more context? What is the story behind this repo? Why did you create this separate repo? Would be curious to know :)

EDIT: maybe we can add a note to deepcake/echo pointing here if it's really true that it is now maintained here.

Bear with me; this is complicated.

Due to the order of these two lines, @removed listeners will be called before the component is actually removed. It's pretty easy to see this in action:

@removed private function onFooRemoved(foo:Foo, entity:Entity):Void {
    trace(foo == entity.get(Foo)); //true
}

At first this seems weird but harmless. However, problems arise if you try to replace one component with another.

@removed private function onFooRemoved(foo:Foo, entity:Entity):Void {
    entity.add(new Bar());
}

@added private function onFooBar(foo:Foo, bar:Bar):Void {
    throw "Entity should not have both Foo and Bar components!";
}

This occurs because during onFooRemoved, the Foo component is still there. If you add Bar, then the entity will be added to ViewOfFooBar, triggering onFooBar.

But it gets worse:

@removed private function onFooRemoved(foo:Foo, entity:Entity):Void {
    entity.add(new Foo());
}

@update private function updateFoo(foo:Foo):Void {
    trace(foo); //null
}

Due to the order of events, Foo is removed after the add(new Foo()) line, meaning the entity remains in ViewOfFoo even though the component is gone. Then the view will continue calling updateFoo().

Lots of problems caused by that particular ordering of lines. So why don't we just swap them?

The reason is that in order to dispatch @removed events at all, the entity's components must still exist. One final lookup is performed to find all the arguments to pass.

Possible solutions:

• Cache the value being removed, fully remove it from the entity, and then dispatch the @removed event using the cached value to fill in the blank. Problem is, dispatchRemovedCallback() would have to be massively rewritten. I'm not sure such a rewrite is even viable, and if it was, I doubt it'd be efficient.
• Postpone the entity.add() call until after remove() is fully resolved. Use an event queue or something. Problem is, when you call add() you expect to be able to call get() right after.