Poor support for functions/namespaces. #749
Conversation
If you look at the specification for `console` [1], you'll note that it's a
namespace, not an interface (like most things). Furthermore, MDN lists its
methods as "static".
But it's a pretty weird namespace IMO, because some of its "functions", like
`count` can have state associated with them.
This causes some problems with our current implementation. Something like:
```
[1].forEach(console.log)
```
Fails, since `this` isn't our window-attached Console instance.
This commit introducing a new `static_XYZ` naming convention which does not
have the class/Self as a receiver:
```
pub fn static_log(values: []JsObject, page: *Page) !void {
```
This turns Console into a namespace for these specific functions, while still
being used normally for those functions that require state.
We could infer this behavior from the first parameter, but that seems more
error prone. For now, I prefer having the explicit `static_` prefix.
[1] https://console.spec.whatwg.org/#console-namespace
|
So the problem this is solving is that the signature of the function we were making has a this pointer as first parameter? |
|
If I understand correctly, then yes, this won't work. For example, this is valid (I'm 100% sure), but doesn't currently work (I assume, I haven't tried): [1].forEach(console.count)Because I don't think your solution would work, because we don't have the object. JS doesn't pass it to us. If we had the I believe the solution is that the global object (i.e. window), is supposed to be holding the state. |
Right, and the Window already is holding that state, (all namespace like are non nullable structs) (see also performance for example) |
If you look at the specification for
console[1], you'll note that it's a namespace, not an interface (like most things). Furthermore, MDN lists its methods as "static".But it's a pretty weird namespace IMO, because some of its "functions", like
countcan have state associated with them.This causes some problems with our current implementation. Something like:
Fails, since
thisisn't our window-attached Console instance.This commit introducing a new
static_XYZnaming convention which does not have the class/Self as a receiver:This turns Console into a namespace for these specific functions, while still being used normally for those functions that require state.
We could infer this behavior from the first parameter, but that seems more error prone. For now, I prefer having the explicit
static_prefix.[1] https://console.spec.whatwg.org/#console-namespace