Allow built-in functions to be construct only #1603
Conversation
|
Is |
|
No, it's an internal function, but it would make sense to expose it regardless of the changes here because it complements duk_is_constructor_call(). |
| @@ -36,6 +36,11 @@ | |||
| * inspection code. | |||
| */ | |||
|
|
|||
| /* FIXME: ES spec: all construct-only functions have [[Call]] and [[Construct]] | |||
There was a problem hiding this comment.
I'm not sure I understand this. I was under the impression that [[Call]] and [[Construct]] are specification devices, so what does it mean for compliance, in practical terms, to say a function "doesn't have [[Call]]"?
There was a problem hiding this comment.
This was just a cryptic note to myself so maybe not very readable ;)
In ES all functions have [[Call]], and constructable functions also have [[Construct]]. Functions that are construct-only in the specification reject non-constructor calls specifically by checking for it. All of this is the conceptual specification view.
Right now in this pull the CALLABLE flag behaves differently. It's not set for construct-only functions so that attempts to call them as normal functions will get automatically rejected without any explicit check in the function. So, CALLABLE <!=> [[Call]]. This affects a bunch of checks inside; when the code is supposed to check for existence of [[Call]], the internals needs to check for CALLABLE | CONSTRUCTABLE to get the same effect.
This may be confusing, which is why the FIXME.
There was a problem hiding this comment.
I understood, I was just trying to figure what it meant in practice--since if there's no observable difference in behavior then it doesn't matter for compliance. But I guess in this case the difference would be that the thrown error would not have the function in its stack trace, while it would in a compliant engine.
There was a problem hiding this comment.
It would just be an internal difference - the main concern being that DUK_HOBJECT_IS_CALLABLE(x) would be different than "has [[Call]]". At present they are the same in master. This might be error prone when maintaining code unless the naming was changed to make the distinction clearer.
The stack trace behavior would be different from current behavior, but stack traces are not compliancy related.
There was a problem hiding this comment.
Alright, I see. I was just trying to figure out what needed to be "fixed" (since it's a FIXME). As long as you know the answer to that, I'm satisfied. :)
There was a problem hiding this comment.
Hehe, yes. I don't keep work in progress branches in a well commented state btw. That's why they're work in progress :)
With the explicit DUK_HOBJECT_FLAG_CALLABLE it's now possible to create functions that are constructable but not callable as normal functions. This is a prototype branch to see how that would work out in practice for built-in functions. The upside would be that no explicit
duk_require_constructor_call()would be required which is smaller (and slightly faster). It would then be possible to expose a public API to create non-constructor and construct-only functions.Work in progress.