I'm writing two OntologyEditFunctions in support of one Object Type - a function to back the main Action to create Objects, and a function to back the main Modify Action.

This Object Type has upwards of 50 properties, each of which I want my functions to take as inputs. Additionally, for a couple of fields, I take input in one type and transform it into another before storing it (e.g. take a string that can contain a number, then extract the number and store it as a Double). This means I'm going to have at least two function signatures like:

@OntologyEditFunction()
public myFunc(
    a: string,
    b: string,
    c?: Double,
    .....
    cm?: Timestamp,
    cn?: LocalDate,
    co?: string,
    .....
    //And on and on into something resembling infinity
): void {}

...where all but maybe three or four parameters are identical across the two (and probably eventually more) signatures.

So I'd like to separately define the parameters that don't change (if not all of them), and then reuse that definition in the OntologyEditFunctions. Based on this answer to another question, I tried these:

import { OntologyEditFunction, Double, Timestamp } from '@foundry/functions-api';

function baseFunc(
    a: string,
    b?: Double
)
type baseParams = Parameters<typeof baseFunc>;

function testFunc1(add?: string, ...args: baseParams): string {
    a = 'Oh boy it works';
    return a; //...Or not
}
let test1: string = testFunc1('Please', 'work', 0)

function testFunc2<T extends baseParams>(...args: [...T, add?: string]): string {
    a = 'Maybe this time?';
    return a; //Not a chance
}
let test2: string = testFunc2('No', 0, 'dice')
 
export class myClass {
    @OntologyEditFunction() //k and q below were not included in the baseFunc
    public createRecord(k?: string, q?: string, ...args: baseParams): void {
        let foo = a;
    }

    @OntologyEditFunction()
    public modifyRecord<T extends baseParams>(...args: [...T, k?: Double, q?: Timestamp]): void {
        let foo = a;
    }
}

So, testFunc2 and modifyRecord fail at a minimum because the parameters lose their names, which I explicitly want to reuse.

testFunc1 and createRecord each show a pretty encouraging call signature in the tooltip when I hover over their symbols:

• function testFunc1(add?: string, a: string, b?: number | undefined): string
• function createRecord(k?: string, q?: string, a: string, b?: number | undefined): void

...but despite this, in the body of each function, I get a compiler error saying it "Cannot find name 'a'." I was surprised when the call signatures appeared to work, then less surprised when the code failed anyway.

The immediate question is: What did I do wrong with my attempts above, and can they be made to work?

The more pressing question overall is: How can I reuse a set of named & typed parameters in multiple function calls, instead of flooding my document with 80,000 repeated parameters? Or is there another way to condense the code and avoid repetition?

And for major bonus brownie points: Is there a method that also works for Typescript object definitions, so I can use a construct built from the same definition to help assign to the created/modified Object? Something like:

const cols: Partial<myObjectType> = {
    ...baseParamsMod,
    k: k,
    q: q
}
const newRecord = Objects.create().myObjectType(id);
Object.assign(newRecord, cols);

I'm working with two (and later potentially more) functions that each have upwards of 50 parameters, the vast majority of which are identical. So at least two function signatures like:

public myFunc(
    a: string,
    b: string,
    c?: number,
    .....
    cy?: boolean,
    cz?: Date,
    da?: string,
    db?: boolean,
    .....
    //And on and on into something resembling infinity
): void {}

...where all but maybe three or four parameters are identical across the signatures. Note that the parameter names in the real functions are things like username, userId, dateLastEdited, etc.

I want to separately define the parameters that don't change, and then reuse that definition in the function implementation signatures.

Essentially, I want the function signatures to read like "Use this set of pre-defined named parameters, and also here's a few extra parameters unique to this function." Aside from condensing the code, this would make it significantly easier to keep track of how the parameters differ.

Note, many of the parameters that I want to pre-define are optional and must be captured as such.

Based on this answer to another question, I tried these (updated based on feedback from @Ontologize to help focus the question):

type baseParams = [
    a: string,
    b?: Double //I need to capture that this parameter is optional
];

function testFunc1(requiredParam: string, ...args: baseParams, optionalParam?: string): string {
    a = 'Oh boy it works';
    return a; //...Or not
}
let test1: string = testFunc1('Please', 'work', 0)

function testFunc2<T extends baseParams>(...args: [requiredParam: string, ...T, optionalParam?: string]): string {
    a = 'Maybe this time?';
    return a; //Not a chance
}
let test2: string = testFunc2('No', 0, 'dice')

So, these functions fail for several reasons, including:

• During argument expansion, the parameters lose their names, which I explicitly want to reuse.
• In testFunc1, I'm trying to put an optional parameter after a rest parameter, which of course is not allowed. I'm not sure how else to add optional parameters unique to that function, though, given that the rest parameter needs to include required parameters (which I'm pretty sure is also not allowed).

There's more, but my takeaway is that rest parameters will not work for my needs.

Edit: I did also see an answer (that I've since lost track of) where they achieved named parameters by passing them in as an object, like:

type baseParams = {
    a: string,
    b?: Double //I need to capture that this parameter is optional
}

function testFunc3(requiredParam: string, args: baseParams, optionalParam?: string): string {
    args['a'] = 'Oh boy does it work?';
    return args['a'];
}
let test1: string = testFunc1('Please', {a: 'work'}, 0)

This returns without issue, but it also doesn't work for my needs; this function is meant to be called by an automated process that can't handle objects as parameters.

So. Instead of flooding my document with 80,000 repeated parameters and making it near impossible to keep track of where they differ, how can I reuse a set of named, typed parameters within multiple call signatures, such that those signatures can be expanded with additional parameters?

...but despite this, in the body of each function, I get a compiler error saying it cannot find the name 'a'. I was surprised when the call signatures appeared to work, then less surprised when the code failed anyway.

...but despite this, in the body of each function, I get a compiler error saying it "Cannot find name 'a'." I was surprised when the call signatures appeared to work, then less surprised when the code failed anyway.

This Object Type has upwards of 50 properties, each of which I want my functions to take as inputs. Additionally, for a couple fields I take input in one type and transform it into another before storing it (e.g. take a string that can contain a number, then extract the number and store it as a Double). This means I'm going to have at least two function signatures like:

...but despite this, in the body of each function I get a compiler error saying it cannot find name 'a'. I was surprised when the call signatures appeared to work, then less surprised when the code failed anyway.

This Object Type has upwards of 50 properties, each of which I want my functions to take as inputs. Additionally, for a couple of fields, I take input in one type and transform it into another before storing it (e.g. take a string that can contain a number, then extract the number and store it as a Double). This means I'm going to have at least two function signatures like:

...but despite this, in the body of each function, I get a compiler error saying it cannot find the name 'a'. I was surprised when the call signatures appeared to work, then less surprised when the code failed anyway.