Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 11:52
    flash-gordon commented #361
  • 07:09
    unixc3t starred dry-rb/dry-types
  • Oct 22 22:33
    patrickclery commented #361
  • Oct 22 21:12
    D1mon starred dry-rb/dry-matcher
  • Oct 22 15:44
    graudeejs starred dry-rb/dry-container
  • Oct 22 08:41
    esparta commented #366
  • Oct 22 08:39
    flash-gordon commented #366
  • Oct 22 08:39

    flash-gordon on master

    Fix error on Dry::Types::Array#… Merge pull request #366 from es… (compare)

  • Oct 22 08:39
    flash-gordon closed #366
  • Oct 22 08:38
    flash-gordon closed #362
  • Oct 22 08:38
    flash-gordon commented #362
  • Oct 22 08:37
    flash-gordon closed #361
  • Oct 22 08:37
    flash-gordon commented #361
  • Oct 22 07:48

    solnic on master

    Adding missing built-in predica… Merge pull request #65 from esp… Merge branch 'release-1.0' (compare)

  • Oct 22 07:47

    solnic on release-1.0

    Adding missing built-in predica… Merge pull request #65 from esp… (compare)

  • Oct 22 07:47
    solnic closed #65
  • Oct 22 07:29
    esparta opened #65
  • Oct 22 07:06
  • Oct 22 06:23
    robturtle starred dry-rb/dry-monads
  • Oct 22 05:15
    Travis esparta/dry-types (array_try_specs) passed (4)
Dung Nguyen
@mmeeoorroo
class Product < Dry::Types::Struct
attribute :category, Category.optional
end
is that correct?
Simon Schmid
@sled
mh... another guess: attribute :category, Types::Strict::Nil | Category
(I'm still learning too)
Dung Nguyen
@mmeeoorroo
still not work, I will learn more :D
thanks @sled
Simon Schmid
@sled
@mmeeoorroo actually the one with | works for me
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