Simplify functions and distinguish methods #244

hudlow · 2025-12-19T19:42:25Z

NOTE THIS IS A BREAKING CHANGE AND NEEDS TO BE CONSIDERED CAREFULLY

As I discussed with @timostamm and @srikrsna-buf, this PR eliminates the "overload" abstraction from the cel-es codebase. Instead, multiple functions (and methods) can have the same name, and each function is responsible for whether it matches a name and/or a set of arguments.

This way, the _&&_ and _||_ functions can still match on any set of arguments and handle short-circuiting in a conformant way — but other functions rely on standard argument-matching logic.

This also lays the groundwork for matching functions via overload_id (which will be necessary if evaluating a checked expression) and matching functions via parameter types instead of argument values.

This PR does introduce unique, generated overload IDs in a different way than #243, but it doesn't attempt to match the IDs to the cel-go implementation.

Unfortunately, the scope grew larger than I intended. If it's necessary, I can try to decompose the work further.

srikrsna-buf

Overall I am quite happy with the simplification of removing overloads and fixing the method vs function problem. Left some comments, still reviewing the rest.

packages/cel/src/ext/strings/strings.ts

packages/cel/src/list.ts

packages/cel/src/map.ts

packages/cel/src/value.ts

packages/cel/src/func.ts

srikrsna-buf · 2025-12-23T12:03:27Z

packages/cel/src/func.ts

+  narrowedByName(name: string): FuncRegistry;
+  narrowedByArgs(...args: [CelResult[]] | [CelResult, CelResult[]]): FuncRegistry;
+  // TODO: narrowedByParams(...args: [CelType[]] | [CelType, CelType[]]): FuncRegistry;


This means we will create a new FuncRegistry for each lookup. Maybe we can avoid the allocation if we club the args and name and just return a Callable | undefined?

I simplified function registry, renamed it back to a dispatcher (to avoid the proto registry confusion), and added a lookup cache.

srikrsna-buf · 2025-12-23T12:05:10Z

packages/cel/src/func.ts

-  find(name: string) {
-    return this.functions.get(name);
-  }
+  withFallback(registry: FuncRegistry): FuncRegistry;


User's will also see this I think we can expose a simpler interface.

I adjusted this to withFallbacks(Callable[]) — let me know what you think. The idea is to make the ordering explicit.

hudlow · 2025-12-23T22:07:57Z

packages/cel/src/std/logic.ts

+  celFunc(olc.SIZE,           [MAP],                  INT,  (x)     =>  BigInt(x.size)),
+
+  celFunc(opc.IN,             [DYN, LIST],            BOOL,             inList),
+  celFunc(opc.IN,             [DYN, MAP],             BOOL, (n, h)  =>  h.has(n as CelMapIndex)),


@srikrsna-buf CelMapIndex is used here.

srikrsna-buf · 2026-01-02T17:47:36Z

packages/cel/src/error.ts

+
+  causes(value: unknown, exprId?: bigint | number): CelError;


I think we can use a function instead for this that is internal like the deleted celErrorMerge which is not exported from the package.

srikrsna-buf · 2026-01-02T17:51:28Z

packages/cel/src/error.ts

  }
 }
+
+function isOfType<T extends CelType>(


Maybe we can move this to type.ts?

srikrsna-buf · 2026-01-02T18:01:33Z

packages/cel/src/func.ts

-export interface Dispatcher {
-  find(name: string): CallDispatch | undefined;
-}
+export interface Callable<R extends CelType = CelType> {


Because the interface is public via celFunc and celMethod I think it will be useful to add the doc comments back

srikrsna-buf · 2026-01-02T18:03:24Z

packages/cel/src/func.ts

-export interface Dispatcher {
-  find(name: string): CallDispatch | undefined;
-}
+export interface Callable<R extends CelType = CelType> {


I am not sure making the result generic is useful. We can simplify if we use CelType directly.

srikrsna-buf · 2026-01-02T18:05:36Z

packages/cel/src/func.ts


-  get parameters() {
-    return this._parameters;
+export function celFunc<const P extends TypeTuple, const R extends CelType>(


Doc comments for celFunc

srikrsna-buf · 2026-01-02T18:28:45Z

packages/cel/src/error.ts

+
+  if (errors.length) return errors[0].causes(errors.slice(1));
+
+  return results as CelValue[];


I think we should return unwrapped here

srikrsna-buf · 2026-01-02T18:29:11Z

packages/cel/src/error.ts

+  const unwrapped = results.reduce((u, r, i) => {
+    return u.concat([
+      types ? unwrapResult(r, types[i], i + 1) : unwrapResult(r),
+    ]);
+  }, [] as CelResult[]);
+
+  const errors = unwrapped.filter((r) => isCelError(r));


Nit: Using a regular loop we can do it in one go

srikrsna-buf · 2026-01-02T18:34:39Z

packages/cel/src/func.ts

+  }
+
+  call(id: number, args: CelResult[]): CelResultFromType<R> {
+    const target = unwrapResult(args[0], this._target);


There could be a subtle bug here unwrapResult expects a CelResult which can never be undefined but here the args can be an empty list and args[0] will return undefined. I think we should replicate matchArgs to be safe

srikrsna-buf · 2026-01-02T18:44:05Z

packages/cel/src/func.ts

+  readonly #callables: Callable[];
+  readonly #nameCache: Map<string, Dispatcher | undefined> = new Map();
+  readonly #overloadIdCache: Map<string, Callable | undefined> = new Map();


We deliberately don't use JS private fields to support older runtimes. This is anyway an internal class we can just use TS private fields

srikrsna-buf · 2026-01-02T18:46:32Z

packages/cel/src/planner.ts

  }
  eval(ctx: Activation): CelResult {
-    const vals = coerceToValues(this.values.map((x) => x.eval(ctx)));
+    const vals = unwrapResultTuple(this.values.map((x) => x.eval(ctx)));


We don't want to unwrap here because we want the Any unwrap to be lazy

Simplify functions and distinguish methods

66f13bb

hudlow requested a review from srikrsna-buf December 19, 2025 19:42

Revert time function changes that failed in Node 20.x

cb0c89b

srikrsna-buf reviewed Dec 23, 2025

View reviewed changes

hudlow mentioned this pull request Dec 23, 2025

Simplify, fix, and add tests for timestamp and duration handling #245

Merged

Merge remote-tracking branch 'origin/main' into hudlow/noverloads

80c1f50

hudlow force-pushed the hudlow/noverloads branch from 517d0f1 to f0d0d2f Compare December 23, 2025 17:11

Revert rename of registry to protoRegistry

922890e

hudlow force-pushed the hudlow/noverloads branch from f0d0d2f to 922890e Compare December 23, 2025 17:12

hudlow added 3 commits December 23, 2025 15:05

Simplify types per review feedback

447a5d8

Improve formatting of function tables

2211622

revert unnecessary rename

284559f

hudlow commented Dec 23, 2025

View reviewed changes

hudlow added 2 commits December 23, 2025 17:26

Revert unneeded changes for value conversion

dc1a8fa

Make interface members readonly per review comment

622bba6

hudlow mentioned this pull request Dec 24, 2025

Generate enums for operators and overloads #243

Open

hudlow requested a review from srikrsna-buf December 30, 2025 15:35

srikrsna-buf reviewed Jan 2, 2026

View reviewed changes


		if (errors.length) return errors[0].causes(errors.slice(1));

		return results as CelValue[];

Simplify functions and distinguish methods #244

Are you sure you want to change the base?

Simplify functions and distinguish methods #244

Conversation

hudlow commented Dec 19, 2025

Uh oh!

srikrsna-buf left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants