3 ms·
> Or perhaps there are non-obvious blockers that make it too hard? To me, it seems like you'd need a new language.
by simlevesque 4y ago
> Or perhaps there are non-obvious blockers that make it too hard?
To me, it seems like you'd need a new language.
- danenania 4y agoWhy is that? I may be missing something, but they're already enforcing permissions at runtime, which seems like the hard part to me. It would 'just' need to be integrated with the call stack so you know which dependency(ies) want system/network access.
- zdragnar 4y agoIIRC there are all sorts of issues around monkey-patching prototypes, shared objects between modules, etc. which would readily allow escaping any sort of module / dependency level permissions system. You'd probably be better off pitching a typescript subset language with its own compiler / interpreter rather than trying to shoehorn it into V8.
- danenania 4y agoThese seem like solvable problems. Prototype modifications are rare these days and should probably be restricted in the same way that system/network access is. Shared objects between modules also seem like an edge case apart from callbacks? I posted an idea on how to handle callbacks upthread a bit: https://news.ycombinator.com/item?id=31326123#31332061 https://news.ycombinator.com/item?id=31326123#31332061
- zdragnar 4y agoSystem and network access are all done via the runtime library functions, which are easy to control. Changing prototype access almost certainly involves modifying V8 in unpleasant ways, and I'm not sure how you would get around the overhead of deno needing to the call stack on every function call- statically analyzing when a function is operating in one context or another is certainly not a trivial problem.