Yang,
I see. My intent had been to put a reference to the metadata object
directly in the Script object so no weak map would be required -- the
metadata would live as long as Script, Script would just have gotten a
little bigger. But, since there's no compelling use case, it's all academic.
It is true that Scripts are already listed in the weak array list. However,
that's hidden in V8. So if we were to keep a weak list of scripts to
metadata mapping, that would work fine. If we did this on the embedder
side, then we'd need something else than script IDs as keys.
Looking forward to
Yang,
Thanks for your response. I've decided to bail out on the metadata part of
my proposal for the very reason you indicated -- it's kind of a niche
application and, in many ways, a time-based cache makes more sense for my
application. I'll submit a CL soon to add GitScriptSource
and
To understand this a bit better, the reason a map from script to metadata
doesn't work for you, when implemented on the embedder side, is that you
can't have a weak map with script IDs as keys?
I'm concerned that since this seems like a niche use case, adding
another field to Script objects is
Thanks Yang,
FWIW, it appears that one can effectively disable the prepareStackTrace API
by setting Error.stackTraceLimit to 0. Fortunately, this does not affect
Exception::StackTrace. But you knew that.
My impression of import.meta is that it's a way of the environment passing
information
Hi,
I think the hurdle for a C++ API is a lot lower, and I can see the
usefulness of GetScriptSource as you suggest.
I'm somewhat indifferent about a metadata object. Isn't that a bit like
import.meta for modules?
Cheers,
Yang
On Wed, Feb 17, 2021 at 2:43 PM Alex Kodat
wrote:
> Thanks
Thanks Yang,
Got it on prepareStackTrace -- it's a funny and sketchy beast. getThis and
getFunction are particularly beyond the pale in terms of encapsulation. In
fact, it wouldn't hurt to have a flag to disable the API.
In hindsight, the right solution is for me to use
Generally I would discourage adding more non-spec features to the V8's JS
implementation. In the long run, these non-spec features cause
compatibility problems, and often are a security nightmare. They also add
unnecessary complexity to maintain. The reason we have not removed the
On Wed, Feb 17, 2021 at 5:42 AM Alex Kodat wrote:
>
> It was pretty trivial to add these so it doesn't seem like there's a major
> downside, so does it seem reasonable to submit a CL for this? I'd offer to
> fix up the doc at https://v8.dev/docs/stack-trace-api if it does, but, of
> course, I
In managing a menagerie of scripts from various sources, I've found it
useful to enhance CallSite locally to have two additional functions
getScriptId and getScriptSource. The former provides a unique identifier
for the script that contains the code in the stack frame and the latter
access to
10 matches
Mail list logo
