jamescourtney
commented
8 months ago Thanks for the contribution! Give me a couple of days to mull this over; FlatSharp's unions used to support behavior similar to this. The reason that I moved away from it was for performance reasons. Basically, if you implement your visitor as a struct, the JIT can make things faster by removing virtual method calls and object allocations for the delegates.
The other is that newer syntax innovations have made an interface implementation lighter weight than it used to be. In terms of lines of code, this isn't that different than inline delegates:
class MyClass
{
void DoSomething(SomeUnion union)
{
union.Accept(new SimpleVisitor());
}
private struct SimpleVisitor : SomeUnion.Visitor<int>
{
public int VisitDog(Dog d) => d.Age;
public int VisitCat(Cat c) => c.LivesRemaining;
}
}The general rule I try to follow is that I assume people are using FlatBuffers because they care about performance, so I try to structure the APIs to encourage performance.
That said, I completely see your reasoning. My day job isn't terribly performance-sensitive, so I'd probably also be irritated that these unions don't support a .Match pattern :)
parched
codecov[bot]
This is one of the changes we have in the fork we're using at our company.
It adds a
Matchmethod to unions similar to other unions in the C# ecosystem, e.g., OneOf, dunet.It avoids the need to create a visitor class for one time use.
We use it like this:
If you're happy to accept a change like this. I'll tidy it up a bit and add tests where necessary.