Skip to content
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

Object type and BusObject interface #252

Open
ilyapashuk opened this issue Aug 1, 2021 · 3 comments
Open

Object type and BusObject interface #252

ilyapashuk opened this issue Aug 1, 2021 · 3 comments

Comments

@ilyapashuk
Copy link

hello.

why Object struct and BusObject interface both exist?

can I call conn.Object and cast the result to *Object?

why don't return Object instead BusObject?

How I can add signal matchings on objects if BusObject can't be casted to Object?

@invidian
Copy link

invidian commented Dec 1, 2021

why don't return Object instead BusObject?

why Object struct and BusObject interface both exist?

Given that Object is exported, I agree just an Object could be returned.

How I can add signal matchings on objects if BusObject can't be casted to Object?

IIUC, you can't. They are global for connections right now IIRC, so you can add a match, then filter when receiving the singals for the ones you care about.

There is actually more related to this issue. Right now if one wants to put Conn behind the interface, there is no way to replace BusObject with your own interface, tied down to your needs for example, which is important when mocking and when doing the dependency inversion.

@guelfey
Copy link
Member

guelfey commented Jan 5, 2022

How I can add signal matchings on objects if BusObject can't be casted to Object?

Indeed, you can use conn.Signal to receive signals and then filter based on that, but you need AddMatch first - the existing method on Object is just a wrapper for this (D-Bus) method call.

There is actually more related to this issue. Right now if one wants to put Conn behind the interface, there is no way to replace BusObject with your own interface, tied down to your needs for example, which is important when mocking and when doing the dependency inversion.

Not sure if I understand your issue here - since BusObject is an interface, if you put Conn behind an interface, then create a mock implementation of it, you can also just return a mock implementation of BusObject, or am I missing something?

@invidian
Copy link

invidian commented Jan 5, 2022

Not sure if I understand your issue here - since BusObject is an interface, if you put Conn behind an interface, then create a mock implementation of it, you can also just return a mock implementation of BusObject, or am I missing something?

Yes, if you implement entire BusObject, then things will work. However, in v5 BusObject has 11 methods, while in my use case, I only need CallWithContext(). There is no point in relying on entire BusObject for me.

As I had a break from working on this code, it may not be completely accurate, but from what I recall, the solution for my particular issue would be to have a function taking an interface, which would be a subset of Conn struct functionality and returns BusObject. This way, one only need to implement what's actually needed to create a BusObject.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants