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

refactor: GetURL() -> GetLocator() #22

Merged
merged 2 commits into from
Sep 2, 2024
Merged

Conversation

KevFan
Copy link
Contributor

@KevFan KevFan commented Aug 22, 2024

Description

Closes: #10

Rename GetURL() to GetIdentity() GetLocator() as it broad and intuitively suggests that the method returns a unique identifier for the object. It doesn’t carry any specific technical connotations (like URL or UID) that might mislead users. It also aligns well with the idea of uniquely identifying an object within the Policy Machinery topology, regardless of whether it is a cluster object or an in-memory object without implying a specific format

An alternative that might suit also is GetRef()/GetReference() that aligns with the targetRef concept.

@@ -15,10 +15,10 @@ type Object interface {

GetNamespace() string
GetName() string
GetURL() string
GetIdentity() string
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An alternative that might suit also is GetRef()/GetReference() that aligns with the targetRef concept 🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about something along the lines of "reference" too. Maybe ReferentId or ReferentIdentifier or yet ReferentUniqueId, ReferentUID, etc. It makes sense for objects that are meant to be linked to others in the topology (from a targetRef or from any kind of reference really).

But truth is this is about uniquely identifying the objects before being about linking them. I suppose a more generic term that captures this idea, that is extensible to unlinked objects too, is preferable. It bothers me though that "UID" is taken and we cannot use it 😕

"Identity" is good. I don't love it though. IDK why. Maybe because it's too close to UID and we don't want people to get confused about these two.

Other options that crossed to mind include Handle and Locator.

Either "identity", "handle" or "locator" (or anything along these lines really), another open question I have regards to qualifying the term:

  • "unique", to explicit this constraint
  • "topology", to denote purpose – though arguably it can be used to other purposes too
  • "descriptive" or "semantic", in contrast to "opaque" (like Kube's UID)

So, any combination of these could work. E.g. "TopologyUniqueId", "DescriptiveHandle", "UniqueSemanticLocator" 🤯

Anyway... Right now I'm kinda leaning to "locator". But I also don't know why. WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, yeah Identity sounds closely related to the kube UID 🤔 I like Locator or UniqueLocator if we are choosing a combination 👍

@Boomatang Do you have any thoughts on this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have that strong of an opinion on the naming. The term to Locator sounds good, it gives a good indication of what the resulting function return should be used for.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated GetUrl() to GetLocator()

@KevFan KevFan self-assigned this Aug 26, 2024
Copy link
Contributor

@Boomatang Boomatang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am happy with these changes.

Copy link
Contributor

@guicassolato guicassolato left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🏅

@guicassolato guicassolato changed the title refactor: GetURL() -> GetIdentity() refactor: GetURL() -> GetLocator() Aug 30, 2024
@KevFan KevFan merged commit e5173b2 into Kuadrant:main Sep 2, 2024
6 checks passed
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

Successfully merging this pull request may close these issues.

Rethink "URL" of the Object interface
3 participants