Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unify IAsyncTexlFunction #2751

Open
MikeStall opened this issue Nov 25, 2024 · 0 comments
Open

Unify IAsyncTexlFunction #2751

MikeStall opened this issue Nov 25, 2024 · 0 comments

Comments

@MikeStall
Copy link
Contributor

MikeStall commented Nov 25, 2024

We shouldn't have 5+ variations of IAysncTexlFunction plus AsyncFunctionPtr delegate.

We should be able to remove this branch in EvalVisitor and have it be a single dispatch.

IReadOnlyDictionary<TexlFunction, IAsyncTexlFunction> extraFunctions = _services.GetService<IReadOnlyDictionary<TexlFunction, IAsyncTexlFunction>>();

Ideally, unify across:

  1. builtin invocations
  2. UDFs
  3. Custom Functions (ReflectionFunction)

Broader design things to consider:

  • can we unify with StandardErrorHandlingAsync?
  • can we still follow Least-privilege? At least with many interfaces, the functions are describing statically which subset of functionality they need.

This is an engineering hygiene issue. Need to come up with a good design.

MikeStall added a commit that referenced this issue Jan 22, 2025
Address #2751.  
This unifies most of them. To scope this PR, there are subissues on 2751
for remaining issues.



We have a plethora of IAsyncTexlFunction* interfaces. Want to
consolidate on 1, and make it public.

This 
Ttake the parameters on the various IAsyncTexlFunction* overloads and
move them as properties on a new public `FunctionInvokerInfo` class. And
then have a new IAsyncTexlFunction* that takes the invoker. And remove
all the others, migrating them onto this - and fixing the various
bugs/hacks along the way that would impede migration.

Most fundamentally, this FunctionInvokerInfo must have access to
interpreter state and so must live in the interpreter. (Whereas some of
the IAsyncFunction* interfaces live in core).

Successfully removes several here so we get a net reduction, and shows a
path to remove the rest.

This problem quickly touches other problems:
- **How to map from the TexlFunction to the invoker**. This is made more
complicated because we register on PowerFxConfig, but that lives in
Fx.Core and can't refer to interpreter implementations.
- **dll layering around Fx.Json**: Some function implementations live in
Fx.Json, but that specifically _does not_ depend on interpreter (because
it is included by PowerApps).
- **Standard Pipeline**: how to handle default args, common error
handling scenarios, etc. Today, that's still in interpreter. Whereas we
really want those checks to be in the IR and shared across front-ends
(and available to designer).
- **Split up Library.cs and class** - we have one giant class, partial
over many files, containing 100s of function impls. Just give each impl
its own file, similar to how we did for TexlFunction and the static
declarations.
- **lack of unit testing**: Today, most of our interpreter coverage
comes from .txt files. But we should have C# unit tests on interpreter
classes that provide coverage on core classes, like EvalVisitor.

Some related prereq fixes that will directly help here:
- Can we remove runner/context from Join? and leverage LambdaValue -
which already closes over these.
- fix Json layering problem. 
- IsType/AsType _UO shouldn't live in Json. They should work on any UO.
- Remove _additionalFunctions from the serviceProvider.

---------

Co-authored-by: Mike <jmstall@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant