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 hey man, I want to release dry-types 0.10.0 with these two changes you’ve made
you ok with that?
I tested it against rom/rom-sql, looks good
Nikita Shilnikov
@flash-gordon
@solnic yes, feel free
Piotr Solnica
@solnic
I bumped to 0.10.0 btw
since meta change is (a bit) significant
Piotr Solnica
@solnic
@flash-gordon bad news, specs in my app started to fail when I upgraded to dry-t 0.10 :(
Oskar Szrajer
@gotar
I have a question, there is logger automatically created for dry-web, can I overwrite it somehow? Normal way do not works: There is already an item registered with the key "logger" (Dry::Container::Error). I want to change it to force logger to log to STDOUT, not to file
Piotr Solnica
@solnic
@gotar it’s a configuration setting
Nikita Shilnikov
@flash-gordon
@solnic what's wrong?
Piotr Solnica
@solnic
that’s the funny part, I have no clue
worse part - specs pass when run individually
Nikita Shilnikov
@flash-gordon
oh wow, love that
Piotr Solnica
@solnic
which makes me think there’s some global state
that keeps changing between spec runs
and some specs depend on it and they fail
Piotr Solnica
@solnic
all failures are related to structs being initialized with a missing attribute
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