🐛 zx: Prevent collisions between methods, signals and properties

[bachp]

Prevent collisons by adding an explicit suffix to properties and signals.

If a collision is detected a _ is added to the identifier until there is no more collision.

Closes:

• Name collisions in generated Proxy code when propery getter/setter exists as a method #231
• xmlgen: property setter can conflict with target interface provided setter method #169

[zeenix]

Thanks so much for contributing this PR and also to follow our dev practices from the start. However, I think a good solution here would require more work than changing all generated names.

[zeenix]

LGTM otherwise.

[zeenix]

I think the 2 steps should be combined into one. We don't really need a separate type for name collision, just one for creating identifiers, that ensures that the identifier isn't already used.

[bachp]

First I also tought this, but the to_identifier is also used in other places, eg. function parameters, and they don't collide with signals and properties. but

I could move the to_identifier function inside the avoid_collision but I thought this was it is more explict

[bachp]

I was just wondering if there is a case where we also have collisions in arguments?

[zeenix]

First I also tought this

Ah, you're ahead of me. :)

I could move the to_identifier function inside the avoid_collision but I thought this was it is more explict

Or you could have the new API use to_identifier itself so that caller doesn't need to care. I'd call the type UniqueNameGenerator and method identifier_for_name, which takes the name as arg, also taking care of to_snakecase. You can suggest a better name, just don't like collision in the name (sounds negative 😆).

I was just wondering if there is a case where we also have collisions in arguments?

Doubtful but even if there was, it won't be global (i-e args of different methods can have the same name).

[bachp]

I tried severl variants of combining operations. In the end I found it's best to keep the operations separate so I can combine these in the different cases:

• Functions and signals i need to_snakecase, to_identifier and make_unique
• For Properties I need to_snakecase, to_identifier, and I need make_unique as a separate operation depending on read or write case.
• For arguments I only need to_identifier, optionally we could apply make_unique per function here but I don't see this needed.

So my solution now is to just rename the CollisionHandler to Idenfifier and have a make_unique method.

[zeenix]

• Functions and signals i need to_snakecase, to_identifier and make_unique

As I wrote, it would be best to just abstract it all. The caller should just ask for a unique identifier for the name and that's it.

• For Properties I need to_snakecase, to_identifier, and I need make_unique as a separate operation depending on read or write case.

From what I can tell from your commit, it's basically doing the same thing. Of course, it would make sense to have a separate API for properties in UniqueNameGenerator, e.g property_getter and property_setter (or it could just be property with a boolean arg that tells the direction. Then identifier_for_name could just be method.

• For arguments I only need to_identifier, optionally we could apply make_unique per function here but I don't see this needed.

👍

[bachp]

I am not sure what you are asking now.

As I see it the current implementation has several functions/methods (to_snakecase, to_identifier and make_unique) that can be combined ot form the final identifier.

The rules how these need to be combined for the different cases are applied locally where the element (method, property, signal and arguments) are processed.

The way I understand your proposal is to put the rules how to combine these into separate functions/methods and just call them, e.g. to_method,to_signal, to_property and to_argument? While I can do that I'm not convinced it is a good idea as it basically splits the rules into two locations.

[zeenix]

The way I understand your proposal is to put the rules how to combine these into separate functions/methods and just call them, e.g. to_method,to_signal, to_property and to_argument

At the very least, it should have been clear, which names I proposed. :)

While I can do that I'm not convinced it is a good idea as it basically splits the rules into two locations.

How so? They'll do pretty much the same thing as you're doing right now, just in one place/type. They will all use to_snakecase and to_identifier, for example.

[zeenix]

Let me know, if you'd want me to make the proposed changes in a separate commit on top.

[bachp]

I did a test with these changes and the NetworkManager dbus xml, and it doesn't solve all the conflicts. I need to dig a bit deeper. I think I will add a test case using the NetworkManager interface description to make the issue more reproducible.

[zeenix]

@bachp oh I'm so sorry. I never got a notification that you requested a review after updating the pr. I'll look into this very soon.

Thanks for your patience. 🙏

[bachp]

@zeenix As mentioned in #722 (comment) my change didn't completely solve the issue with the networkmanager dbus specification. Unfortunately I was busy with other things.

I want to add a test based on the real world example, not sure when I will get to it tough.

[zeenix]

@bachp i hope you've not forgotten about your existing PR. 😉

[bachp]

@zeenix No I did not but I ran into other issues while trying to interact with network manager, mainly #312 which is more of a blocker for me.I will come back to this once I found a solution for the more blocking issues.