#Function.call
split shard
@sinful crane, is the cyclic reference a problem or do we have a way of handling that? ObjectTypeDef.Functions: [Function!] ↔ Function.FromType: ObjectTypeDef.
sinful crane
We have a similar cyclic reference between Module.Functions <=> Function.ModuleID which is currently handled very painfully
What's Function.FromType? don't see that anywhere
oh is that what you're adding
split shard
Yeah, trying to. I need to know the parent from a Function.call.
sinful crane
Can you get away with just an object name instead?
We have all the objects defined in full at the top level now, everywhere else is just a reference. (That changed from before)
so if you want to keep it an ObjectTypeDef, you can just have it be a reference
sinful crane
We have a similar cyclic reference between `Module.Functions` <=> `Function.Modu...
(to de-vague: when calculating a module's ID/digest, we recursively remove all the ModuleIDs from its inner functions, and then add them back when they're needed)
split shard
Can you get away with just an object name instead?
For the CLI, yes I think so, since I'm only trying to call top-level functions.
split shard
so if you want to keep it an ObjectTypeDef, you can just have it be a reference
Not sure I understand
sinful crane
I'm not sure if you're familiar with how it used to work, but it used to be like this: Module = [Function(returnTypeDef, argTypeDefs...)]. When a custom type was encountered, the returnTypeDef or argTypeDefs would embed the object definition in full - so with all of its functions attached. But it would only do this the first time it saw that object; the rest would be just references (an ObjectTypeDef with a name but no fields or functions).
Now, it's Module = [Object(fields, functions)] - the functions and fields still embed typeDefs, but now they can always just be references, because all objects are defined in full at the module-level
if my ad-hoc syntax makes sense there 😅
I can hop on a call too if you like
split shard
I can hop on a call too if you like
Yup 🙂
sinful crane
will join dev-audio in a sec!
split shard
Fyi, function call is working.
Wondering dagger do list vs dagger do --help. Natural since you'll need dagger do message --help to see the arguments. Also avoids conflict with a function named list.
Bikeshedding: How about dagger call [function] instead of dagger do [function]? do was used for commands/cli, this way we can keep function calls from the CLI independent to drop call later or use do for something else.