Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Piotr Solnica
@solnic
@flash-gordon got it
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
Nikita Shilnikov
@flash-gordon
@solnic because we need to support things like hash[type]
in some way
Piotr Solnica
@solnic
where?
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
Nikita Shilnikov
@flash-gordon
tbh the reason I did this is that we don't have type ast transformations yet, otherwise I'd trim a tree with excluding metas
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
Nikita Shilnikov
@flash-gordon
this can be done with .with(meta: {})
Piotr Solnica
@solnic
that’s a tough one
I wonder what’s less surprising to be honest
Nikita Shilnikov
@flash-gordon
exactly
Piotr Solnica
@solnic
ie ROM::SQL::Types::Int.meta(primary_key: true) == ROM::SQL::Types::Int # true does not look reasonable
those two things mean two different things after all
this can easily bite us in many places
Nikita Shilnikov
@flash-gordon
but I'd say relying on this is a bad idea
Piotr Solnica
@solnic
we use various enumerable methods to find attributes so…dunno
why you think that?
Nikita Shilnikov
@flash-gordon
why would you compare two types like this? Why would compare them at all?
Piotr Solnica
@solnic
we do that man and it is useful
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
Nikita Shilnikov
@flash-gordon
@solnic don't get me wrong, I don't say they are the same, I'm just wondering how this is used
Piotr Solnica
@solnic
can’t remember exact places
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 :(
Nikita Shilnikov
@flash-gordon
two different approaches are using a type as something that acts as a type and using a type like an object, I think that's the difference
@solnic so we need a method to strip out meta, wdyt?
Piotr Solnica
@solnic
Type#pristine? O_o
but if AST transformations could be used to trim types for special purposes, then maybe we should focus on that
Nikita Shilnikov
@flash-gordon
whatever name you like :) Even with AST this would be useful. The only difference is that AST trimming will trim the whole tree, that is erase meta from underlying types as well
@solnic OK, you now can merge this one https://github.com/dry-rb/dry-types/pull/188/files and I will add Type#pristine tomorrow
Piotr Solnica
@solnic
right
we’ll see what makes sense
Nikita Shilnikov
@flash-gordon
and in the next version we'll add AST transformations, this will make Type#pristine better. That's the plan. I think
I also pushed a small fix for Any
Piotr Solnica
@solnic
I saw that, cool
can I release 0.10.1 later today?
Nikita Shilnikov
@flash-gordon
yes