worse part - specs pass when run individually
that keeps changing between spec runs
and some specs depend on it and they fail
we missed the fact we no longer equalize on :meta too
for some reason it broke some other things
as ie
Types::String == Types::String.meta(i_am: “different”) returns true
which is a bug
you wrote specs that specifically check if this works like that, so I wonder why?
we set meta to empty hash by default, so
Types::String == Types::String.meta({}) # true
in some way
types with different meta are not the same, so I don’t think it’s a good idea to treat them as such
oh, yes, the latter is now solved since we have an empty hash by default, but anyway
and I'm not sure whether it's a good idea to use meta in comparisons. But I'm OK with that. So we need another way to drop
meta then
I wonder what’s less surprising to be honest
those two things mean two different things after all
this can easily bite us in many places
why you think that?
ie projecting attributes and then using
uniq
or checking if an attribute exist in a schema
all these things rely on equality
and in general it’s about semantics too, like in this PK example I showed, two types, one with special meaning, they are not the same
besides, for hash-based mappings we can use a different method for getting some identifier for a type object
but it’s clearly used given that our specs started to fail
would be good to track it down of course, but I don’t have time :(
@solnic so we need a method to strip out
meta, wdyt?
but if AST transformations could be used to trim types for special purposes, then maybe we should focus on that