Isiah, that works when you're in full control of all the code. However,
when you're writing B, and A is 3rd party (or the reverse in DI cases) then
the API is out of your control. In cases like that, it's better if the data
itself knew the restrictions. That keeps dependencies low.
On Mon, Jan 14,
We agree trying to learn about the caller should not affect how the caller
works. That's why I was thinking more on the lines of an "id" carried
around by every function object. As long as that "id" uniquely identified
the function without providing any access to the function itself, it would
satis
You could substitute a function parameter accepting an object here or a
class instance for globals to dodge this. Doesn't change my point.
Here's how you deal with permissions like that: have A know what data B is
allowed to access, then pass B an object with only that data. If necessary,
make the
"who calls function B" has, and must have, no bearing on how function B
behaves. Every single call site that passes identical (`Object.is`)
arguments must behave the same. Am I misunderstanding what you mean?
On Sun, Jan 13, 2019 at 9:50 PM Ranando King wrote:
> That's all fine and dandy until y
That's all fine and dandy until you're dealing with a project that has a
"no globals" mandate. The problem that I'd want to be able to solve is one
of gaining and losing control during a single function's execution.
For example: say function A is privileged, but function B is not. Function
A calls
As for security, scope control is usually the more important thing to
monitor. That's covered in realms for the most part, but also a few other
things. Stack traces don't play a major part here, and whenever untrusted
calls need made and tracked through the stack, it's not that hard to just
save an
You may be interested in this: https://github.com/tc39/proposal-error-stacks
On Sun, Jan 13, 2019 at 22:02 Ranando King wrote:
> ES used to have Function.caller for traversing the call stack, but
> apparently this was very problematic for engine development and prevented
> various optimizations.
ES used to have Function.caller for traversing the call stack, but
apparently this was very problematic for engine development and prevented
various optimizations. So now it doesn't work in strict mode which makes it
useless for code involving `"use strict"` or `class`. One of the main use
cases fo
8 matches
Mail list logo
