TC39 Decorators
2022-05-05
plaintext logs
prev next
source on github
00:01
<Mathieu Hofman>
So in the first case of runtime checks, I need the param decorator to be able to modify the function in such a way that param validation can run when the function is invoked (hopefully without requiring to decorate the function itself).
00:01
<Mathieu Hofman>
And in the second case, I need to annotate the object literal's method parameters in such a way that a related helper can read the annotations starting from the object itself
01:33
<rbuckton>
But you should still be able to add an initializer to the function/method definition, no? so it'd just be a runtime error to add an initializer to the rest param?
addInitializer (normal and rest params) would be for adding initializers in general, while returning an initializer would be for piping through the passed argument (non rest params). So addInitializer would probably be what you would use in this case.
01:38
<rbuckton>

In other words, you'd write the string decorator above like this:

const string = (_, { index, addInitializer }) => {
  addInitializer((...args) => {
    if (typeof args[index] !== "string") throw new TypeError();
  });
};
01:41
<Mathieu Hofman>
Well and probably return the value if valid, right ?
01:41
<Mathieu Hofman>
oh I see this is an init on the method
01:42
<Mathieu Hofman>
How would a validator that coerces work in this pattern?
01:42
<rbuckton>

But also be able to add runtime metadata so that I can do things like:

import { remotable, awaited } from 'rpc-lib';

const foo = remotable({
  foo: (@awaited thing) => {
    if (myCollection.has(thing)) {
      ...
    } else {
      ...
    }
  }
});

Where the remotable helper (which could be written as an object literal decorator) would be able to get the annotations for the foo method on the object it received, and (to really simplify) build a new object with a new foo method that will implicitly await on the first argument.

Not sure where I stand on object literal decorators since theres f({}) and {} |> f(%)
01:43
<rbuckton>
If pipe was F#, we could have added a backpipe as well like f <| { }
01:43
<Mathieu Hofman>

Not sure where I stand on object literal decorators since theres f({}) and {} |> f(%)

Yup, that's why I excluded it. But I do want to make sure that one way or another I can get at the annotations

01:45
<rbuckton>
Js-choi had thoughts about block decorators as a way to do comprehensions, similar to F# computation expressions
01:47
<rbuckton>
https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/computation-expressions
01:51
<rbuckton>

Something like

const q = @query do {
  for (const x of ar) {
    if (x > 1) yield x;
  }
};
01:52
<rbuckton>
Except F# computation expressions can add keywords. Not sure if I'd support that