Don't eat proxy trait

[zeenix]

In GitLab by @grodin on Dec 6, 2021, 23:46

It wasn't clear that when you write

#[dbus_proxy]
trait SomeTrait {

}

that the struct that is generated for you has all the functions and methods of the trait, but doesn't actually implement it, and in fact effectively replaces it.

It was confusing the heck out of me that I couldn't write a function

fn foo<T: SomeTrait>(t: T) {}

without the compiler complaining that the trait wasn't in scope. It was only after I used cargo-expand to check what was actually generated that it became clear that the scope was "replaced" by the struct.

It would be great if the generated struct actually did implement the trait, and the trait remained, but not knowing much about macros, I've no idea if this is possible.

[zeenix]

Thanks for reporting this. I think it'd be indeed better if we didn't replace the trait but rather implemented it. At least that's what we should try first and if (for any reason) it doesn't work, we can document it better.

We're pretty short on developer time these days so if you could give it a shot, that would help in making this happen sooner.

[zeenix]

Adding "API break" tag cause keeping the source trait around could easily conflict with other symbols in the module (e.g the trait impl via dbus_interface macro).

[zeenix]

This would be a pre-requisite for #236.

[zeenix]

This would be a pre-requisite for #236.

Actually, not necessarily. dbus_interface can generate the dbus_proxy for you. That way you've far less typing involved and this can be done w/o breaking API though introduction of new macro attribute(s).

[TTWNO]

This is actually exactly what we did with atspi a couple years ago and I removed all that code because it was such a hassle to maintain the macro... specifically for the original reason stated, using the trait as a generic.

[zeenix]

@TTWNO I'm not sure I follow. Are you referring to what's stated in the description or my last comment?

[TTWNO]

The initial description. Having the trait passed through the macro would be very useful!

[zeenix]

The initial description. Having the trait passed through the macro would be very useful!

Thanks. So interface generating the proxy doesn't help there I'm guessing?

I'm just wondering how you handle this right with interface-generated proxy. It certainly complicates that.

Perhaps there should be a new attribute to disable keeping the proxy and interface sets this by default. 🤔

[zeenix]

There is a problem that I'm not sure how to solve here: The signal methods are not actually implemented by the proxy macro but rather API is generated for receiving these signals. IOW, the generated impl doesn't exactly implemented the trait user provides.

Until I (or someone else) can find a good solution to this, I'm not sure this can be done. So I'm removing this from 5.0 milestone.

[TTWNO]

I'm just wondering how you handle this right with interface-generated proxy. It certainly complicates that.

This was some time ago, but I removed all the code that tried to use that feature. I ended up just adding a bunch of separate traits and implementing them on the proxies when necessary.

[bachp]

There is a problem that I'm not sure how to solve here: The signal methods are not actually implemented by the proxy macro but rather API is generated for receiving these signals. IOW, the generated impl doesn't exactly implemented the trait user provides.

Until I (or someone else) can find a good solution to this, I'm not sure this can be done. So I'm removing this from 5.0 milestone.

Would a possible solution be to expose the trait not exactly as written, but enhanced by the macro? This way the trait would cover all methods of the generated proxy, while still allowing alternative implementations for example for mocking or testing.

[zeenix]

Would a possible solution be to expose the trait not exactly as written, but enhanced by the macro?

Hmm.. sounds strange though and we might end up with the same issue as this was originally created for: Users expecting their input to be all there but then finding out that the signals are missing.

while still allowing alternative implementations for example for mocking or testing.

You don't really need to mock the proxy, given that we allow creation of in-process socket pairs now, which you can use to put a (mock/test) service on one side and a real proxy on the other.

---

Btw, since you're active here again, any chance you'll be finishing your old PR?