# Duplicate FQCNs for different things **URL:** \ **Category:** Collection Development\ **Created:** [August 13, 2024, 2:31pm UTC](https://forum.ansible.com/t/duplicate-fqcns-for-different-things/7823 "2024-08-13T14:31:09Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![utoddl](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/utoddl/32/249_2.png) [@utoddl](https://forum.ansible.com/u/utoddl)\ **Post date:** [August 13, 2024, 2:31pm UTC](https://forum.ansible.com/t/duplicate-fqcns-for-different-things/7823/1 "2024-08-13T14:31:09Z")
Continuing the discussion from [De-duplicated warnings?](http://forum.ansible.com/t/de-duplicated-warnings/7814/2): Excellent! That’s good information, and works really well for my use case. What I’ve done surprised me a bit b/c naming things is hard. In our local collection (which should be named “`local.`_something_” but history happened) I’ve got a module and a filter, both named `mw.cc.warn`. That seems to work. I guess Ansible can figure out from context which one it should use. That leads me to wonder: Do you think some day we might [_edit_ have] fully qualified names for collection-scoped variables? For example, `mw.cc.rolea.varnamea`. We sort of fake it now with `mw_cc_rolea_varnamea`, but that’s merely a naming convention. ---
**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\ **Post date:** [August 13, 2024, 2:36pm UTC](https://forum.ansible.com/t/duplicate-fqcns-for-different-things/7823/2 "2024-08-13T14:36:22Z")
This probably cannot happen as Jinja already uses ‘.’ notation to equate to dictionary keys ` x.y == x['y']` and Python underneath also uses it for object properties and methods `x.keys` ---
**Author:** ![utoddl](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/utoddl/32/249_2.png) [@utoddl](https://forum.ansible.com/u/utoddl)\ **Post date:** [August 13, 2024, 3:46pm UTC](https://forum.ansible.com/t/duplicate-fqcns-for-different-things/7823/3 "2024-08-13T15:46:58Z")
Fair enough. What about — and I know we’re blue-skying here — someday perhaps promoting `__` beyond a mere naming convention into something real with support at the core level? Granted that we have to overlook the vast chasm of extant names to even entertain the discussion. If we start from the ideal rather than where we currently are, try to imagine how “general qualified naming” would look for _everything_: collections, roles, plugins, variables, tags, and whatever else I’m forgetting. For this example I’ll stick with “`.`” just to facilitate discussion, acknowledging current Jinja issues etc. Consider the unqualified tag “`foo`”. We all know what that means: it’s a “global” tag, as all tags currently are. A fully qualified tag “`nn.cc.rr.foo`” would be a “`foo`” tag scoped to the “`rr`” role in the “`nn.cc`” collection. The unqualified tag “`foo`” would/could match any fully or partially qualified tag ending in “`\.?foo$`”. But a partially qualified tag “`.foo`” might match only in the playbook, but not in any local or imported/included roles. Another partially qualified tag “`.fee.foo`” is scoped to a local “`roles/fee`” role, but not to any collection roles (as collections assets should always be fully qualified). I’ve thought about this a lot (although it must look like I’m making this up as I type). No doubt it would need some serious re-thinking to work the same way for “general qualified naming” of everything. Whether there’s a way to build a bridge from here to there is another discussion. [ducks] ---
**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\ **Post date:** [August 13, 2024, 3:58pm UTC](https://forum.ansible.com/t/duplicate-fqcns-for-different-things/7823/4 "2024-08-13T15:58:45Z")
If we were to revamp variables , I would start here [redesign variable interface · Issue #127 · ansible/proposals · GitHub](https://github.com/ansible/proposals/issues/127). It needs to be updated for collections (this predates them by a lot) but that is something that can be expanded upon there.