https://pantsbuild.org/ logo
Join Slack
Powered by
I am deep diving into how the hell we should handl...
# development
h
I am deep diving into how the hell we should handle unions. Got some ideas, will try and mock something up as a proof-of-concept we can beat up on
❤️ 2
🐍 1
💞 1
🚟 1
f
Is Python's typing sufficient to allow us to define a type signature for the non-implicit parameters shared by the various union implementations?
Then you could "call" something with that signature.
Copy code
@union_callable
async def publish(field_set: PublishFieldSet) -> PublishResult: ...

await publish(MyFieldSet(...))
A function marked with 
@union_callable
would be restricted to a single parameter which is the union in question. (All other parameters to union impls would need to be implicit.)
No body would be provided (and 
...
would be mandatory).
h
What would determine which rule to invoke on each union member though?
f
The actual type of the parameter, right?
The rule visitor would need to store away the union type when processing 
@union_callable
which is the type of the sole explicit parameter
and the actual type is available when the await happens
so whatever trampoline is injected by the engine should be able to figure out what to call
or is that too much like a 
Get
(in that the engine has to search for the impl instead of knowing it by name)
h
Yeah, exactly. We want to get rid of all that.
what we want is virtual methods…
Which, maybe could actually work
f
Maybe union types should have a base class containing a "vtable"?
(or the engine sets up some sort of dict keyed on actual type and rule signature with the value as the actual rule to invoke)
10 Views
Open in Slack
PreviousNext
Powered by