Skip to content

blippy: introduce BlippyOrd<T> to order notes containing non-Ord types - #11290

Open
jgallagher wants to merge 1 commit into
mainfrom
john/blippy-ord
Open

jgallagher wants to merge 1 commit into
mainfrom
john/blippy-ord

Conversation

@jgallagher

Copy link
Copy Markdown
Contributor

This is an alternative to #11284. I'm not at all sure it's better; I don't really love either of them. I wanted to try "stick a non-Ord type in an Ord wrapper" and since I have this compiling, figured I could open this and we could compare.

@bnaecker bnaecker left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I like this approach too. I think I have a weak preference for this over #11284, which it uses the "normal" Ord machinery. But using a dedicated method as in that PR has benefits, mostly around explicitness and being harder to misuse. Either seems strictly better than what we have!

IdOrdMap<OmicronZoneExternalFloatingIp>,
);

impl std::cmp::PartialOrd for OmicronZoneExternalFloatingIps {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I like this part :)

DuplicateUnderlayIp {
zone1: BlueprintZoneConfig,
zone2: BlueprintZoneConfig,
zone1: BlippyOrd<BlueprintZoneConfig>,

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Does it matter that this will show up in the Debug output? As in, do we want to "delegate" that to the implementation on the inner type? I don't know how often we look at that representation, maybe there are special "reporting" methods we lean on instead.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Mm yeah good call. If we go with this route I'll remove the #[derive(Debug)], and manually implement it as a pass through to the inner type's Debug.

@davepacheco davepacheco left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

This is okay, but I don't like that this approach permeates all the places the type gets used instead of being localized to the bits that need the ordering.

Comment on lines +149 to +153
impl<T: Clone> From<&'_ T> for BlippyOrd<T> {
fn from(value: &'_ T) -> Self {
Self(value.clone())
}
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Why do we need this?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

It makes some of the conversions shorter 🤷‍♂️. Blippy works almost entirely in terms of references, except when it needs to construct a note, at which point it clones. I could remove this and some foo.into()s would turn into foo.clone().into()?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I was more wondering: why can't the BlippyOrd contain the reference in that case?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

It might be able to. I suspect that ends up causing ownership issues somewhere or we would've used references for all the types contained by Kind already, but I could try it and see.

@davepacheco

Copy link
Copy Markdown
Collaborator

I wonder if there's something in between, where we create a separate type that impls Ord + PartialOrd for Kind, but that we only create during sorting (similar to when we have a fn display(&self) -> impl Display).

@jgallagher

Copy link
Copy Markdown
Contributor Author

I wonder if there's something in between, where we create a separate type that impls Ord + PartialOrd for Kind, but that we only create during sorting (similar to when we have a fn display(&self) -> impl Display).

I don't know how we'd do that without the concrete type that we return being a duplicate of the entire Kind enum (essentially exactly what I have on this PR, with something like BlippyOrd<_> for all the zone configs)?

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.

3 participants