idupree/Lasercake — comment on commit 862c1d44fe50653186f7a5a849c9fcfcc7898b5e
File:  line 0
By elidupree:

All of the world.hpp code for my way:

class interiorness_equivalence_class {
public:
interiorness_equivalence_class(tile_contents c):data(c);
bool operator==(interiorness_equivalence_class other)const { return data == other.data; }
bool operator!=(interiorness_equivalence_class other)const { return !(*this == other); }
private:
tile_contents data;
};

All of the world.hpp code for your way:

inline tile_contents interiorness_equivalence_class_representative(tile_contents t) {
return t;
}
inline bool interiorness_equivalent(tile_contents t1, tile_contents t2) {
return interiorness_equivalence_class_representative(t1) == interiorness_equivalence_class_representative(t2);
}

Neither of those seems so much more not-worth-it to me.

Actually, we need to change this name more deeply. "Interiorness"? Interiorness of what? Right now, there's no term for the 'what', and this is really about the 'what'. Right now we're saying "Are these contents equivalent in terms of, uh, whatever concept it is that we care about for the purposes of interiorness?" That's why it's called "interiorness_checking_type" - because THE CONCEPT is the one for which we CHECK when we're considering interiorness. It's NOT the interiorness, it's the THING ON WHICH WE DO INTERIORNESS CHECKING, hence the name. You can't just remove "checking". Your "tile_contents_equivalent_for_interiorness()" is a better name, admittedly, but it's still...

Of course, the underlying concept isn't a real concept, since it's dictated by how we think about interiorness. So I think it's a better idea to rephrase it to NOT refer to the underlying concept... and there are two different ways we use this, one of which requires transitivity and the other of which doesn't... so, I guess...

bool it_is_okay_for_tiles_with_these_contents_to_be_marked_interior_when_they_are_neighbors(tile_contents, tile_contents);
bool a_tile_can_switch_freely_between_these_contents_without_changing_any_interiorness(tile_contents, tile_contents);

I'm pretty sure those are the right names, subject to conciseness. And for the moment, they can both just be implemented as "a == b"