-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(ecmascript): Callable #539
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is exactly what I was thinking, yes.
... But now that I see it and read the spec a little more, it might be that we should just rename Function
to Callable
and add Proxy
there. The spec says this about callable objects:
an object is a member of the built-in type Object; and a function is a callable object.
and
In addition, some objects are callable; these are referred to as functions or function objects
ie. The spec is saying that "whenever I say 'function', what I mean is any kind of actual function or a callable Proxy". And this is validated by how the spec is written. So the Function
enum doesn't actually correspond to anything in the spec... It does make sense from a human standpoint but it might not make actual sense from the code standpoint...
is_callable
definitely should return Callable
, and basically every place where we have Function
as a parameter or saved in a struct should indeed have Callable
... The only question is if there will remain any places whatsoever where the Function
enum would remain at all?
} | ||
Callable::BuiltinPromiseCollectorFunction => todo!(), | ||
Callable::BuiltinProxyRevokerFunction => todo!(), | ||
Callable::Proxy(d) => write!(f, "PROXY_DISCRIMINANT({:?})", d), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick: Should be Proxy({:?)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you! fixed to 2e8bba3
Callable::BuiltinPromiseResolvingFunction(d) => agent[d].object_index, | ||
Callable::BuiltinPromiseCollectorFunction => todo!(), | ||
Callable::BuiltinProxyRevokerFunction => todo!(), | ||
Callable::Proxy(_) => todo!(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick: This should be unreachable as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you! return None 91f9ae7
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just call unreachable!()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it, I’ve made the changes! d491dbb
Yeah, I was also wondering if that might be the right approach while trying to refactor this. I was a bit unsure about when we would actually need to treat Function and Callable separately. Should we go ahead and rewrite function.rs as callable.rs, or should we merge this PR and gradually replace the places using Function with Callable? If we decide to go with the former, I think we can go ahead and close this PR. What do you think? 👀 |
I'm a bit unsure. If we add Proxy to Function and rename it to Callable, then we'll get basically all we want the easy way. But! It might still be that there's a place somewhere where the spec does actually rule out callable Proxies, and if that is the case then we'll have removed the enum that would've been used to represent that. The worst thing is that we won't see that case in our code if we just rename Function to Callable. But, if we do go ahead with a separate Callable then we're going to do a lot of work that might end up being entirely unnecessary :/ |
A quick search through the spec suggests that Proxies are never categorically separated from callable objects, so a closing this PR and just renaming Function to Callable seems proper. |
I have created Callable as a new implementation. I copied the contents of function.rs and added Proxy to each function.
Now, I’m thinking of rewriting is_callable as follows:
However, if I do this, it will cause compilation errors in all the places where is_callable is currently being used. Since the existing functions mostly accept Function, this behavior seems natural.
At this stage, does this implementation approach for Callable align with the intended design?