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
Remove type safety from Interface #38
Comments
The side effect is improved runtime performance.😂 |
I'm not very happy with this idea. |
If the interface field types do not match, there is now a panic at The following code didn't compile well before, but it does now. struct MyObj;
#[Object]
impl MyObj {
async fn a(&self) -> &str {}
}
#[Interface(field(name = "a", type = "String"))]
struct MyInterface(MyObj); This actually seems reasonable, it simplifies the definition of the interface. |
Panic is not desirable. I believe there is a solution that involves traits but I'm unable to work on it currently. |
@phated |
@sunli829 is it possible to use a macro to add additional methods to a trait, including a default implementation? That is the solution I am considering. |
I am hoping to find time to understand macros better, but my other open source responsibilities are requiring my time right now. Tomorrow I am giving a presentation on |
@phated I tried this on a new branch. In addition, thank you very much for the support of |
🙇 Thank you! Your work on this project is amazing and I very much appreciate it! I am excited to help out more. |
@sunli829 I think it is a great Idea especially when it panics at application start. I never really liked the implementation of Interface. I think it is somehow reversed. Isn’t there a more natural way where Interface behaves more like a trait? So that Objects and SimpleObjects can "implement" it rather than beeing passed into the interface as struct fields? It just feels wrong and doesn’t allow shareing an interface over crate boundaries. @phated Is your presentation being recorded? I would love to see it. |
@nicolaiunrein The interface definition is not natural, but it is simple enough to use.😁 |
The type safety of the interface causes some functionality to be unavailable. I'll remove the compile-time type safety of the interface and check it when I call
Schema::new
. It doesn't have any performance loss, but there is no guarantee that a compile-time type safety, I think it is worth to do so.The text was updated successfully, but these errors were encountered: