I think my gut says this is ok as-is, but I think we should discuss: What if we added an assert enforcing that flipX and flipY can't both be false?

On one hand it's somewhat confusing to have a widget called Transform.flip that doesn't flip anything. Users may try it without knowing about flipX/flipY and be confused that nothing flips.

On the other hand, it may be convenient to be able to use a Transform.flip that flips based on some state without having to exclude it from the widget tree.

What do you think?

We could use a List and fill it with the axes needed, empty list would mean no flip, but there would need to be a list and we could assert that

Rereading this now, I think the best option is probably to keep it as-is.

I think a list is going to have the same problem by defaulting to an empty list plus more possibilities for invalid configuration.

We could default flipX and flipY to true, but I think it's okay to trust the user here and default them to false.

I agree: I don't think we should assert here, precisely because it might be used in a situation where two variables are both false, and the suggestion to use a List would make it more complicated than it needs to be.

Another thing to think about: Is there a better way to represent this? For example, an enum with values like x, y, both, and none. Kind of similar to Axis.

I'm not saying that flipX/flipY aren't the best way to do this already, just starting a discussion again.

I think two bools here is probably fine, given that it's a specialized constructor already. I can't think of any other ways that "flip" might be interpreted here, unless we also want to incorporate 90 degree rotations (which I don't think we do), and making it an enum makes it harder to write a call to the constructor using a boolean (which is probably the main use case here).

"true" => "isTrue"

I have just done this in my recent commit

What effect does the -1 z value have?

I applied matrix rotation and got this. So I thought I should preserve the value. It does not, however, affect the appearance as far as I noticed

Ah I see, ok let's keep it 👍

You shouldn't need to supply -1 in Z, you're just doing a 2D flip. I'd just always set it to 1.

Making Z constant to reduce unnecessary computation 👍

Nit: I would usually turn this test into a group and then turn each pumpWidget below into a separate test. That way you give each feature tested a chance to fail during one run and give a bit more info. Up to you if you think it's useful or not here, though.

Just bumping this to make sure you saw it, though it's fine if you want to keep it as-is.

Let's keep it as-is.

Nit: One small thing that might make this test somewhat fragile is that we're always expecting tappedRed to be true, so this test would pass for a big gesture detector that didn't flip at all. It would be more reassuring if you could test that the tap did not cause tappedRed to become true when nothing is flipped. Maybe do something like test that tapping topRight, bottomLeft, and bottomRight don't set tappedRed to true when there is no flip?

Up to you though, maybe it's not worth it to add that complexity.

I am a little behind schedule in a few of my college assignments. So, in my opinion, it is not worth adding the complexity at this time.

Let me know your thoughts :)

Rereading this now, I think the best option is probably to keep it as-is.

I think a list is going to have the same problem by defaulting to an empty list plus more possibilities for invalid configuration.

We could default flipX and flipY to true, but I think it's okay to trust the user here and default them to false.

Ah I see, ok let's keep it 👍

Just bumping this to make sure you saw it, though it's fine if you want to keep it as-is.

I think two bools here is probably fine, given that it's a specialized constructor already. I can't think of any other ways that "flip" might be interpreted here, unless we also want to incorporate 90 degree rotations (which I don't think we do), and making it an enum makes it harder to write a call to the constructor using a boolean (which is probably the main use case here).

You might mention that flipping it in both is equivalent to a 180 degree rotation.

What happens if the alignment is Alignment.upperLeft and both are flipped? Does it just draw nothing? Or does it draw outside of its bounding box?

Actually, the more I think about it, isn't any alignment other than center going to draw nothing, or draw outside of its bounding box as long as one flip is true? That seems undesirable, since both are surprising.

It draws outside the bounding box if alignment is something other than center. Being restrictive, we could just fix the alignment to Alignment.center and not provide the option to change it at all. But allowing it may help someone desiring the undesirable results. But they could also do it using the main Transform() constructor. But again, the purpose of this flip constructor is to just simplify and be descriptive of what is being done. What do you prefer?

In that case, I think I'd prefer if we just eliminate the alignment argument altogether and just fix it at Alignment.center. It's surprising to have it draw outside of its bounding box, and if they want to do that, they can do it using the main constructor. We can always add it later if a compelling use case arises.