Right now, all non-castable argument unwrapping just goes through the XPConnect unwrapping code. This is fine for the moment, since all our non-castable things at the moment are external (not new binding) things. But long-term we'll have non-castable new-binding unwrapping, and doing that via XPConnect is silly. We can do it faster with a simple unwrap to nsISupports + QI, and should.
Oh, this also means we need to differentiate, in the .conf file, between "non-castable" and "external". The latter implies the former, of course.
Do we need this for implements to be useful?
Hmm. I think we actually don't need this at all. I dunno what I was thinking when I wrote it... In particular, since "implements" just imports methods onto prototypes and we're not going to try to share generated code between such imported methods, we would just unwrap to whatever concrete class the prototype is supposed to unwrap to and everything should Just Work.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
Bah, I'm on crack. We need this for _arguments_, not for this-unwrapping, of course. So "implements" is useful without this, but only as long as there is nothing that takes the RHS of the "implements" as an argument... Also, I think we need to make sure that if an interface X is a consequential interface of something and is used as an argument then it's not marked as castable. Just flagging consequential interfaces in the parser and then checking the above condition in the codegen should do the trick.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Oh and "need" is a strong word. The current setup works; it just makes arguments that are a consequential interface slower than they could be.
6 years ago
Depends on: 764456
I filed bug 764456 on comment 4. Going to leave this for the separate codegen for non-castable non-external stuff.
You need to log in before you can comment on or make changes to this bug.