Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 12 21:34
    flash-gordon commented #376
  • Dec 12 21:34
    flash-gordon labeled #376
  • Dec 12 21:34
    flash-gordon opened #376
  • Dec 12 19:32
    RyanLafferty starred dry-rb/dry-types
  • Dec 12 05:53
    technofreak starred dry-rb/dry-monads
  • Dec 12 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
Simon Schmid
@sled
ah nope
Dung Nguyen
@mmeeoorroo
the | works with this trick: Product.new({id: 1}.merge(category: nil))
Piotr Solnica
@solnic
@sled I use separate struct classes, one with a category and one w/o a category
Dung Nguyen
@mmeeoorroo
magic :D
Piotr Solnica
@solnic
a product with category would be a separate concept in my app
vs a product w/o a category
Simon Schmid
@sled

`a_type = Hypo::Types::Strict::Nil | Hyp::Types::Address

a_type[nil] => nil

a_type[Hypo::Types::Address.new] => TypeError: #<Hypo::Types::Address address_line1=nil, ...> is not a symbol nor a string`

Piotr Solnica
@solnic
if you want dynamic behavior just don’t use explicit classes and rely on auto-generated rom structs
this won’t work, struct classes are not types
Hyp::Types[“address”].optional should work but I wouldn’t recommend it
Dung Nguyen
@mmeeoorroo
what's wrong with it?
Piotr Solnica
@solnic
because nil is evil, mostly. your system will start relying on a product-with-or-without-a-category
Simon Schmid
@sled
@solnic but how to handle these permutations? If I have a struct with 3-4 optionals, I'd have to create 4! different variations
also a common scenario is to save "incomplete" forms (e.g auto-saving)
Piotr Solnica
@solnic
I don’t use structs along with forms
I use structs to represent specific concepts in a system, and treat them as values
Simon Schmid
@sled
do you have an example what is meant by a "concept" ? :)
Piotr Solnica
@solnic
a product, a user, a product with a category, a list of products etc
Dung Nguyen
@mmeeoorroo
I have a scenario where I need optional types. When a user delete a product, the app just marks the product as deleted, and tracks that user with attribute :deleted_by, User. That field is nil until the product is deleted
could you give a suggestion on that case?
Simon Schmid
@sled
this is where the permutation starts, i.e Product, ProductWithCategory, DeletedProduct, DeletedProductWithCategory
Piotr Solnica
@solnic
I don’t have a generic answer or suggestion, because it depends on the application domain. I would definitely not used names like FooWithoutBar though.
you need to look at what your application is doing and in which contexts things are needed, these should give you good hints how to name things
if you have contexts where you have all products, including deleted ones, then you can have optional deleted_by I suppose
Simon Schmid
@sled
mh so this gets me thinking, we have a document which can be in a "draft" mode, i.e a lot of optionals, no requirements - just type checking
and then the document is validated and put in a "validated" mode, same fields but with a lot of required attributes
Piotr Solnica
@solnic
sounds like a good use case for sub-types then
John Backus
@backus
So is this Kleisli gem dead? Doesn't seem like the maintainer is interested in it anymore
Piotr Solnica
@solnic
Probably. I dunno
Nikita Shilnikov
@flash-gordon
@backus I think you can ping author on Twitter or via email
Mb someone should fork the repo and republish it as a new gem
Ngan Pham
@ngan
@solnic I'm trying to create a service objects with good validation for input. And I think being able to check the type of a variable (beyond primitive types) would be nice
John Backus
@backus
Eh I'm not that interested in it. I just want to get it updated so that it doesn't monkey patch my ruby environment when I require dry-types :P
I do think dry-rb should fork it though
and reduce it down to the useful functionality without all of the haskell-wannabe syntax
Piotr Solnica
@solnic
We thought about it already
Piotr Solnica
@solnic
Either is fantastic but the rest is meh
dry-monads? :P
I actually thought about dry-fp project with some common abstractions that we use in many places
John Backus
@backus
Nice
dry-monad seems pretty good to me
I really think they will be more useful if the syntactic sugar is ditched
Piotr Solnica
@solnic
Me too
Even Either could be a bit simpler to use. >-> and fmap confused me more then once
John Backus
@backus
mhm

Could their >-> example

result = Right(3) >-> value {
  if value > 1
    Right(value + 3)
  else
    Left("value was less or equal than 1")
  end
} >-> value {
  if value % 2 == 0
    Right(value * 2)
  else
    Left("value was not even")
  end
}

just be re-written such that Right and Left provided the method #bind like so?

Right(3).bind do |value|
  if value > 1
    Right(value + 3)
  else
    Left("value was less or equal than 1")
  end
end.bind do |value|
  if value % 2 == 0
    Right(value * 2)
  else
    Left("value was not even")
  end
end
Tim Riley
@timriley
I’d be up for us having a small set of useful things in either dry-fp or dry-monads
I’m really not the biggest fan of kleisli’s >-> trickery. It makes chaining hard in a lot of cases, I’ve found.
John Backus
@backus
Alright so I can define a dry-validation rule that depends on other values
I can also define a schema that works with arrays as input