Closed jridgewell closed 2 months ago
Some suggestion of standard name fields may still be useful here for clients, e.g. in types saying 'global' | 'class' | 'function' | 'block' | string
, so that they can be presented nicely.
I updated to add these as suggested names.
Should the kind
offset be relative to the preceding kind
? (or absolute for the first start item). This would keep the number small if all scope kinds are grouped somewhere in names
together.
We talked a bit about this during our monthly call. @rbuckton and @szuend are going to take a look and discuss the benefits/cost of relative vs. absolute offsets for these.
Absolute vs. relative offsets for kind
is only as efficient as the source map generator makes it.
If a generator adds a names
entry for a new kind
on-demand, it's less likely to be in sequential order, and could theoretically result in an index that requires a 2+ character Base64VLQ encoding.
If a generator is able to preload all names for kind
in advance to keep them sequential, but may have already added entries to names
(say, due to concatenating multiple inputs into a generated output), the initial kind
is only as efficient as the current names
count, which could be large enough to require a 2+ character Base64VLQ encoding.
If a generator is able to preload all names for kind
in advance to keep them sequential, it may as well do so for all inputs and stuff them at the front of names
, then it would only be as efficient as the total number of names
entries it needed to add.
In the meeting, I was under the mistaken impression that a relative kind
would mutate the counter for names
, but that is not the case as the kind
offset is tracked independently. After giving this more thought, it does seem like a relative kind
makes the most sense. An efficient generator will pack all kind
entries at the front of names
. With a relative kind
, the indices [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]
would be encoded like "ACCCCCCCCCCCCCCCC"
(17 characters), while a non-relative kind
would be encoded like "ACEGIKMOQSUWYacegB"
(18 characters). For fewer than 17 entries there is no difference in the size of the encoded output, but for 17 or more entries, a relative kind
can be more efficiently encoded and stored.
This changes
kind
from an enum of known values, to be an index into thenames
field holding any arbitrary string. This allows us to better accommodate non-JS languages.