FQL to access current Function's `data`

Here is a contrived example UDF body:

Query(Lambda([],
    Let(
      { self: Select("data", Get(Function("doStuff"))) },
      Documents(Select("Account", Var("self")))
    )
))

If there was a special function to reference the current UDF (e.g. CurrentUDF()), this could be made more generic:

Query(Lambda([],
    Let(
      { self: Select("data", Get(CurrentUDF())) },
      Documents(Select("Account", Var("self")))
    )
))

context: I’m playing around with a tool that where it could be convenient to define a UDF body before the name of the function is known. I’d like a “higher”, UDF-making UDF to be able to do this and it gets messy.

So, this is a thought – a low priority quality of life idea.

Interested to hear what you are planning. What kind of metadata would you store on the UDF?

What was most on my mind as I was writing was building an app schema programmatically with information stored in the DB. So you could bootstrap an app from code, but then continue to configure and migrate it without any additional dev setup.

You can actually save UDF body definitions in any document’s data, and it can be used to generate new UDFs. But without actually having higher order UDFs, a UDF “factory” cannot replace the value in the function like a proper closure would. Instead you can provide a configuration object that’s saved in the UDF data, and the UDF can use that for any Schema Refs or other variables that could not be known at the time it was defined.

But also, I expect there could be some additional uses:

  • functions with side-effects, e.g. random number generation
  • global singleton-like object, e.g. getGlobalObject UDF that just returns it’s own data
  • memoization

Though to be fair, many of my thoughts on potential use cases are pretty academic in nature. I assume that if there was a big calling for this, then it would be more apparent. And I’d prefer higher order UDFs to solve my initial use case. So… :man_shrugging: :slight_smile:

1 Like