| 00:06 | <shu> | rbuckton: re: VSCode debugging, i don't know but i wouldn't be surprised if devtools just doesn't work because nobody has looked at it. printf debugging is what we do unfortunately, devtools investment is unlikely to materialize without something like getting to stage 3 first |
| 00:06 | <shu> | yeah, copying into normal objects sounds like it would kill performance indeed |
| 00:06 | <shu> | what are the limitations? attaching behavior and that ownProperty bug? |
| 00:06 | <shu> | (please file issues for the limitations getting in your way in addition to the attaching behaviors thing) |
| 00:27 | <rbuckton> | If I limit this to just the command line compiler, the biggest issue is that I can't emulate our internal NodeArray with a SharedArray. A NodeArray is just an Array with a few extra properties attached, but that causes several issues:
|
| 00:30 | <rbuckton> | We also use data structures like Map that we can't emulate due to the inability to attach behavior, so there's a lot of copying in and out of data structures we can use. |
| 00:33 | <rbuckton> | If I wanted to extend these structs to the language service, we're in the realm of needing behavior and the ability to freeze or lock down specific properties. Our AST is mostly treated as immutable, but if we were to vend struct based nodes from our API they would become unsafe to use if a consumer could make changes to properties outside of a lock. |
| 00:37 | <rbuckton> | For now I've worked around a few other issues. I add a __tag__ field to structs I create when type identity is important, as well as a field containing a pseudo- identity hash so I can use some structs as keys in a shared hashmap implementation I wrote (in place of Map where needed). |
| 00:40 | <rbuckton> | I'm using classes and decorators to fake syntax to better work with the type system, like in the example above. The decorators just collect field names and create a SharedStructType attached to the class, behavior is just defined as static methods. |
| 00:43 | <rbuckton> | I'm also experimenting with a Though the mutex wrapper is slower than |
| 01:11 | <rbuckton> |
|