Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 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
  • Dec 10 10:24
    krautcat starred dry-rb/dry-view
  • Dec 10 10:24
    krautcat starred dry-rb/dry-types
  • Dec 10 10:24
    krautcat starred dry-rb/dry-system
  • Dec 10 10:24
    krautcat starred dry-rb/dry-monads
  • Dec 10 06:55
    IgrekYY starred dry-rb/dry-initializer
  • Dec 09 18:02
    ekremkaraca starred dry-rb/dry-system
  • Dec 09 11:13
    dilcom commented #375
  • Dec 09 10:29
    flash-gordon commented #375
Piotr Solnica
@solnic
default behavior of #messages is to include them
btw more insights about hints/failures here dry-rb/dry-validation#225
Daniel Vandersluis
@dvandersluis
ok I'll check that out.
I'm using dry-v via reform so I'm not sure how I would go about calling the message set, but I'll see what I can figure out
Piotr Solnica
@solnic
@fran-worley ^^^ ??? (again :D)
Daniel Vandersluis
@dvandersluis
:)
Fran Worley
@fran-worley
@blelump good thanks. Just doing the docs for Formular which should help you and is pretty much the last thing before release!
@solnic I was just wondering how your going to merge them. Though the more I think about it the more it makes sense. Funny how long it takes to see something clearly!
Michał Pietrus
@blelump
@fran-worley :fireworks: :sparkles:
Piotr Solnica
@solnic
@fran-worley the class hierarchy is a bit borked, ie Predicate is not the most low-level primitive “rule” type, as it has an identifier, which is a very specific concept in dry-logic - a named rule, so ie Rule::Key is a named rule and…Predicate is a named rule too
so basically we can’t treat predicate objects as some low-level rules
furthermore, the issue with 2 types of return values is troublesome, this must behave in a consistent manner since a rule have a predicate, and that predicate can be another rule OR a predicate itself, this made things more complex than it should be
so essentially we need a single rule concept, with various specialisations, and predicates should be just…methods returning true/false (so ie anonymous blocks or methods from modules/classes/objects that we detach via Method objects)
this should simplify the whole thing, as we’re gonna deal with just one concept - rule
and I’d like to try to keep the idea of “an applied rule” where all args are filled, we’ll see how it goes
the requirement is that rule instantiation must not be too expensive
Piotr Solnica
@solnic
@flash-gordon I was typing a response to that new dry-types issue and SUDDENLY your reply appeared, I freaked out, I freaked out badly :laughing:
Nikita Shilnikov
@flash-gordon
@solnic ah, just the only question I know the answer to :laughing:
Fran Worley
@fran-worley
@solnic makes sense it always seemed kinda irritating that really simple rules with essentially just one predicate had to get wrapped in a rule object. Do you mind if I capture your thoughts above and add them as a comment on the dry-logic PR ?
Michał Pietrus
@blelump
@solnic , thanks for detailed explanation ! Re the container issue, it seems _container comes from dry::container, however when finalize! is performed, it also freezes the system::container itself. I am out of ideas for today , see you tomorrow :-)
Piotr Solnica
@solnic
@blelump oh we just would not finalize! in dev mode, that’s all
Michał Pietrus
@blelump

hi @solnic, I am definietly not a reload–constant guru, but here's what I've found.

Having container without finalization indeed helps and this seems to be the best fit for the dev mode unless you want to explicitly desire some dependency, which hasn't been registered. Only dependencies that are auto–injected are getting registered by default. So if I expect a constant that is on container load path, but didn't get registrered into container, I may call AppContainer.auto_registrar.finalize!. This performs auto registration of all components I've specified in config.auto_register. So far so good, I have everything. Now I change something and it enters:

ActionDispatch::Reloader.to_prepare do
  Object.__send__(:remove_const, :Import)
  AppContainer.instance_variable_set('@_container', ::Concurrent::Hash.new)
  Import = AppContainer.injector
  AppContainer.auto_registrar.finalize!
end

It's not good approach since there're still references to the "old" constants and app crashes after refreshing it.

Besides the above issue, auto_registrar internally calls require_component of the container. The interesting part is Kernel.require which returns false for any n–th load (n > 1) so block doesn't get executed and the container is actually empty, however I am not sure that's the appropriate usage (calling auto_registrar.finalize!).

Igor
@svilenkov
When using dry-initializer how can you add some code to the initialize() method without affecting gems behavior?
Piotr Solnica
@solnic
@blelump I think you should talk to @timriley as I’m almost sure he’d be interested in seeing how hot-reloading of a container could be implemented properly. I won’t have time for this during this week. Way too much mojowork + dry-logic/validation. Sorry ¯_(⊙ʖ⊙)
for rails we probably need to integrate with their AS::Dependencies so it knows about constants loaded by the system
Andrew Kozin
@nepalez
@keeperhood you can just reload the initializer
class MyClass
  extend Dry::Initializer::Mixin

  param :foo

  private

  def initialize(foo, bar)
    @bar = bar
    super(foo)
  end
end
Definitely you have to know a signature of the method to call super properly if you're going to change the signature
Michał Pietrus
@blelump
@solnic , sure! Re AS::Dependencies, my thoughts was similar, however I'm already late due to various issues with hot reloading so I'm going to postpone this task for a while.
Igor
@svilenkov
@nepalez I was thinking the same but what is the signature, it's defined by param values ?
Not sure if super without () would forward arguments if defined as *args
Igor
@svilenkov
I think that will work actually
Just tried in irb
class MyClass
  extend Dry::Initializer::Mixin

  param :foo
  param :bar

  def initialize(*args)
    # do some custom initialization stuff here
    super # calling super without () will forward all arguments
  end
end
Andy Holland
@AMHOL
@solnic is there anything in dry-v to pass through attributes that aren't defined in the validator and just apply validations for the ones that are, use-case being separation of schema/domain validation
Piotr Solnica
@solnic
@AMHOL nope, it rejects unspeced keys
Andy Holland
@AMHOL
Ahh OK, think supporting something like that could be beneficial?
I don't want to duplicate schema validations in domain validators
Andrew Kozin
@nepalez

@keeperhood yes it would. My example displays that you principally can add new arguments of the initializer that does not defined by dry-initializer. But this time you should know what arguments to send to super explicitly.

What Dry::Initializer::Mixin does is provides a module with #initialize method defined, and then includes the module to the class. If you wish not to pollute your class scope with helpers (like param and option), you can make this inclusion explicitly:

class MyClass
  include Dry::Initializer.define -> do
    param :foo
    param :bar
  end
end

In any case what you get is the module with initialize method in a sequence of class ancestors. Then you can work with it via super in a common ruby way.

Piotr Solnica
@solnic
@AMHOL not sure why would that be needed?
Andy Holland
@AMHOL
You're right, was just getting mixed up thinking that if you didn't run predicates on the values it would fail
BTW for at the boundary schema validations do you think they should validate that values are filled and such, or just type validations?
I'm leaning towards just type validations
Piotr Solnica
@solnic
@AMHOL yes at the boundary you simply needs coercions/type-checking but I haven't experimented with separating this yet
Andy Holland
@AMHOL
Cool, give me a shout if you do :+1:
Piotr Solnica
@solnic
my concern is duplication, not sure how to do it without duplication tbf
I duplicated the word duplication
Andy Holland
@AMHOL
lol
Yeah same with me, but thinking about it more, I don't think it's an issue
Don Morrison
@elskwid
duduplication
Andy Holland
@AMHOL
i.e. schemas and validators should both work stand-alone, just that the validator would assume input of the correct type, but should still make assertions on required keys