Skip to content

Conversation

@mbovel
Copy link
Contributor

@mbovel mbovel commented Dec 8, 2025

No description provided.

@SethTisue SethTisue mentioned this pull request Dec 9, 2025
@SethTisue
Copy link
Collaborator

let's merge on Thursday to leave time for feedback, which I've asked for on Discord

Copy link

@spamegg1 spamegg1 left a comment

Choose a reason for hiding this comment

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

LGTM overall


```scala
/** A junction box in 3D space with an associated circuit ID. */
class Box(val x: Long, val y: Long, val z: Long, var circuit: Int):

Choose a reason for hiding this comment

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

Would it look more natural / beginner-friendly as

case class Box(x: Long, y: Long, z: Long, var circuit: Int)

I think it's fine either way, just a thought.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The question is: do we want two boxes that have the same coordinates and same circuit to be ==? I am not sure.

Also, I thought it would impact .pairs, but .combinations actually doesn't use ==. Whereas we use case class or class, we have:

val b1 = Box(1, 2, 3, 0)
val b2 = Box(1, 2, 3, 0)
assert(Seq(b1, b1).pairs.size == 1)
assert(Seq(b1, b2).pairs.size == 1)

So, I am fine with a case class.


## Final Code

See the complete code on [GitHub](https://github.com/scalacenter/scala-advent-of-code/blob/main/2025/src/day08.scala).

Choose a reason for hiding this comment

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

This link is currently missing, I guess the file will be included later on?

Should we just show the whole code here in the article instead? (unless it's too long) Most other articles do that, even though it's a bit repetitive. Again, it's fine either way I think.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The link should work once we merge #912. In general, I prefer to avoid duplicating sources of truth; it’s safer if readers consult the original file directly (which can be CI-tested/linted) rather than a Markdown copy that may drift out of sync. That’s just a general principle though, given that this repo has no CI 😄

@mbovel
Copy link
Contributor Author

mbovel commented Dec 10, 2025

Thanks for the review @spamegg1!

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