Where communities thrive

Join over 1.5M+ people
Join over 100K+ communities
Free without limits
Create your own community

Explore more communities

dry-rb/chat

WE MOVED TO ZULIP => https://dry-rb.zulipchat.com <=

People

Repo info

Activity

00:14

thekuwayama starred dry-rb/dry-monads
Dec 11 09:29

blasterun starred dry-rb/dry-monads
Dec 11 08:34

flash-gordon closed #115
Dec 11 08:34

flash-gordon commented #115
Dec 11 08:31

flash-gordon on v1.3.3

(compare)
Dec 11 08:30

flash-gordon on master

Bump version to 1.3.3 (compare)
Dec 11 08:30

flash-gordon on master

Update CHANGELOG (compare)
Dec 10 23:46

johnmaxwell commented #116
Dec 10 21:54

flash-gordon on master

Halt with mutable backtrace Ex… Merge pull request #116 from jo… (compare)
Dec 10 21:54

flash-gordon closed #116
Dec 10 21:54

flash-gordon commented #116
Dec 10 21:49

johnmaxwell commented #116
Dec 10 21:47

johnmaxwell commented #116
Dec 10 21:43

johnmaxwell commented #116
Dec 10 21:39

johnmaxwell commented #116
Dec 10 21:31

johnmaxwell commented #116
Dec 10 21:22

flash-gordon commented #116
Dec 10 19:41

johnmaxwell opened #116
Dec 10 19:36

johnmaxwell forked
johnmaxwell/dry-monads
Dec 10 10:24

krautcat starred dry-rb/dry-view

Piotr Solnica

@solnic

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

Nikita Shilnikov

@flash-gordon

https://github.com/rom-rb/rom-sql/pull/184/files#diff-93f5db3fcfdb30da17f863f05851ad8fR30 first of all here

https://github.com/hanami/model/blob/ade8bf454f08f0bb066dc878aa962f20f11af299/lib/hanami/model/sql/types.rb#L37-L56 and here

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

Egor Lynko

@flexoid

Hi guys. I have an issue, this simple line of code leads to huge performance impact in my use case
https://github.com/dry-rb/dry-types/blob/master/lib/dry/types/definition.rb#L67

the thing is, I use dry-validation in pair with reform, and my input is a Reform::Form object, which has quite a lot fields by itself, and also parent form in :parent property (recursively to the root form)

so, input.inspectbecomes quite heavy call, and if the property is validated with maybe, it always firstly tried to convert to NilClass, which runs this routine many many times