TC39 Delegates
2022-02-06
plaintext logs
prev next
source on github
05:09
<Jack Works>
reviewing accessor in the decorator proposal
05:10
<Jack Works>
I have a question. In the @logged accessor x example, is it possible to use this.#x to access the derived private field to bypass the decorated accessor and access the original value?
06:56
<ljharb>
it should not be possible to access a private field inside the class body that was declared by the decorator
06:56
<ljharb>
iow, this.#x should only work if the class body declares #x, statically
07:06
<Jack Works>
Then what happened if I write: `#x; @logged accessor x = 1`
09:45
<nicolo-ribaudo>
The accessor uses a different private name; `#x` is a name chosen just to show that they are related in the example.
10:32
<Jack Works>
The accessor uses a different private name; `#x` is a name chosen just to show that they are related in the example.
this is good /
16:57
<devsnek>
decorators on functions when 😭
17:58
<ljharb>
indeed, like symbols, each #x is a different one
18:40
<rbuckton>
decorators on functions when 😭
There's a proposal for function expressions/arrows already
18:42
<rbuckton>
Function decls is trickier since decorating a function decl probably means that function isn't hoisted.
19:34
<devsnek>
imo that doesn't matter in practice but if we get function expressions that's good enough i suppose :(
20:07
<Ashley Claymore>
decorators on nested destructures bindings could be handy
20:43
<rbuckton>
imo that doesn't matter in practice but if we get function expressions that's good enough i suppose :(

It would matter to the TS code base, at least (that is, if we wanted to decorate a function). Quite a bit of the code base is structured like this:

js function f() { return { g, h, } function g() {} function h() {} }

20:43
<rbuckton>
decorators on nested destructures bindings could be handy
For what purpose?
20:44
<devsnek>

It would matter to the TS code base, at least (that is, if we wanted to decorate a function). Quite a bit of the code base is structured like this:

js function f() { return { g, h, } function g() {} function h() {} }

they aren't decorated though
20:44
<devsnek>
its opt in, that's the nice part
20:44
<devsnek>
anyway i don't wanna get into an argument about it, expressions sound "good enough" probably
20:45
<devsnek>
although you'd have to opt into expressions too
20:49
<rbuckton>
its opt in, that's the nice part
My point is that opting in would require breaking from an established convention. In a few small places that's fine, but if it happens more and more often then it's likely the convention would need to change. That leads to huge code moves to conform and would then complicate git history operations like blame, bisect, etc.
20:50
<devsnek>
sure but you need the same changes to use it with expressions 🤷
20:50
<rbuckton>
That's probably a big enough reason we *wouldn't* use function decorators if they were available
20:51
<rbuckton>
sure but you need the same changes to use it with expressions 🤷
Or we just don't use them.
20:52
<rbuckton>
My point is that, while breaking hoisting seems like a sensible choice on the surface, there's a lot more to the iceberg
20:53
<devsnek>
i don't see the difference, both turn the function into a tdz
20:54
<devsnek>
same iceberg
21:35
<Ashley Claymore>
For what purpose?

I was thinking of a niche case, but will try and find a more mainstream use case for when this pattern:

const { x: { a: _a }, b: _b } = y;
const a = f(_a);
const b = f(_b);

Would benefit from this style:

const {
  x: { @f a }, @f b
} = y;
21:49
<devsnek>

I was thinking of a niche case, but will try and find a more mainstream use case for when this pattern:

const { x: { _a }, _b } = y;
const a = f(_a);
const b = f(_b);

Would benefit from this style:

const {
  x: { @f a }, @f b
} = y;
const { @debounce(500) a } = y;