Open thiagowfx opened 1 year ago
cc @whimboo @jgraham @sadym-chromium
The idea is that if you specify a sandbox you always have to provide a name. But internally we use null
to represent the case where it wasn't specified, which mean "no sandbox".
We could of course accept null
as a value here equivalent to not specifying the sandbox
property at all. But I think any change should come in the context of a general discussion about whether we always require the missing value default to be equivalent to a specific valid value.
I am fine with either choice, the point is that these two parts of the spec are contradicting each other at the moment.
It seems your original intent was to have null
as an explicit possible value.
In this case, should we update it to ?sandbox: text / null
to make it consistent with the first item in the description?
(We could of course discuss it further e.g. in the next monthly sync if you think it's warranted.)
I don't think there's a contradiction; there's two different variables with different types.
In pseudo typescript code it's something like
type PreloadScriptEntry = [string, string | null];
class Session {
preloadScriptMap: Map<string, PreloadScriptEntry>;
}
class AddPreloadScriptParameters {
expression: string;
sandbox?: string;
}
class AddPreloadScriptResult {
script: string;
constructor(script: string) {
this.script = script;
}
}
function addPreloadScript(session: Session, parameters: AddPreloadScriptParameters): AddPreloadScriptResult {
let expression = parameters.expression;
let sandbox: text | null = parameters.sandbox ? parameters.sandbox : null;
let script = uuid();
session.preloadScriptMap[script] = [expression, sandbox];
return new AddPreloadScriptResult(script)
}
I get that in typescript this looks kind of odd; we're using undefined
in one place and null
in the other. But spec-wise it makes sense; undefined
isn't usually used as a spec type, so we just directly check if the field is present, and if not use null
for the internal representation, without accepting null
as an explicit value in the JSON (where undefined
also isn't a value). So the spec as-is requires that you either provide a string sandbox
or you omit the field. We don't allow specifying null
as a value, and the fact that the prose uses null
to represent the missing value is totally editorial and doesn't really reflect any implementation constraint.
and the fact that the prose uses
null
to represent the missing value is totally editorial and doesn't really reflect any implementation constraint.
This is the key part. Then this is WAI.
As someone who is getting ramped up in the spec for the first time, I'd say:
Let |sandbox| be the value of the "sandbox" field in |command parameters|, if present, or
undefined
otherwise.
would cause less confusion than the current form:
Let |sandbox| be the value of the
"sandbox"
field in |command parameters|, if present, ornull
otherwise.
And there's precedent for that, e.g.
Let type be the value of the type field of local protocol value or undefined if no such a field.
That said, if it's purely editorial I'll keep it in mind and let the type definition have priority over the prose whenever there's a situation of ambiguity like this.
Thanks for the detailed explanation, and feel free to close this bug (maybe I'd keep it open for a while just in case Maksim or Henrik want to chime in.)
I think we should probably fix this by removing "undefined" from the specification, except where we literally mean the ECMAScript value undefined
. In general there's some cleanup we could do around our use of spec types (e.g. we're representing protocol values as the infra map type, so instead of taking about a field being present, we should write something like if |command parameters| contains "<code>sandbox</code>"
). But that kind of editorial cleanup hasn't been a very high priority.
Follow-up-of: #292
Could you let me know if the following is an error in the spec?
The spec says:
.i.e.
null
is possible. However the type specification is:Should it have been
...instead? Other places in the spec have
/ null
to denote explicit nullability possible.The alternative would be to eliminate the explicit
or null otherwise
language. Here I am specifically thinking ofundefined
vsnull
in TS/JS.I am happy to send a PR if you confirm such a fix is indeed desirable.