Earlier quoted context omitted.
I've had similar thoughts, notably as a way to side-stepping the composability limits of current parsing theory. But these limitation are increasingly worked around... And looking at rust, I can start to imagine a future where macros are powerful enough to support a lot of declarative coding. When coding javascript today I write code like: // can be imported, and api.router() mounted in express let api = new API(...)…
Nice. But also a workaround, right? Because it's not actually declarative, it's APIs that are made to look declarative-ish. So there's several layers of mismatch, for example most of the active ingredients being strings, meaning you're coding mostly in the string-language embedded into JS. We do that a lot. Probably time to start looking at our workarounds (and Macros are another workaround) and figure out what we ar…
I'm not entirely sure what you mean...
In an ideal world "API" would be a keyword, similar to how "class" is a keyword for declaring/defining classes. Example:
API MyApi {
constructor(defaultName) {
this.defaultName = defaultName;
}
/** some description */
method: get
route: /hello-world
scopes: some-permission-string || other-permission-string
{
let name = request.query.name;
if (!name) {
name = this.defaultName;
}
response.send('hello ' + name);
}
}
module.exports = MyApi; // similar to how you would export a class in JS
Whilst my JS code, where I create an API object and call API.declare(...) for each route isn't as neat as having an "API" keyword and code-generation for said keyword, it's pretty close.
I just write the API.declare(...) as something that collects arguments, and then those can be instantiated multiple times... Similar to how a class can be instantiated multiple times.
I do similar things for loading components that depend on each other: declare dependencies, define function for loading using said dependencies -- then have some library code construct a function that loads any desired component with maximum concurrency (by analysing the DAG).