These are chat archives for dry-rb/chat

18th
Aug 2016
Nick Sutterer
@apotonick
Aug 18 2016 07:34
@solnic @AMHOL @timriley question re. terminology: when having this include Container[:component] (pseudo code) on the class, that's called auto-inject, right? what's it called when you only allow the :component to be injected via the constructor, explicitly?
@AMHOL re. the "too many layers" - i would do it exactly the way you do it :sparkles: what i wonder now is what's the view's job then, in a dry world? dispatching to the actual template?
Tim Riley
@timriley
Aug 18 2016 08:38
@apotonick that's just plain constructor DI, then, if you're not auto-injecting anything.
Nick Sutterer
@apotonick
Aug 18 2016 08:45
@timriley ok! that makes sense. the constructor DI is done with dry-constructor or whatever the gem was called, right?
one thing i don't understand is: when using auto-inject, you basically use a global variable, right? the container constant that is then "included" in class will refer to all the dependencies. does that mean the dependencies are set at compile-time?
or let's put it the other way round: i can't see why it's called auto-inject, because it's more like it auto-instantiates from a container that gets set at compile-time, so it's not really an injection, isn't it?
Nikita Shilnikov
@flash-gordon
Aug 18 2016 08:52
@apotonick the actual injection is done at runtime, when you use include Import[:foobar] it's just builds some ruby code for you which will be invoked later, at runtime
include Import[:foobar] checks if something registered under :foobar, but it doesn't extracts/unwraps/whatevers it
Nick Sutterer
@apotonick
Aug 18 2016 08:55
@flash-gordon yeah but it could also instantiate the same instance later, so it's not really an injection? because the container is a global constant set at compile time?
i know the "injection" happens at run-time when the object is created, but the "injected" instance comes from a global container, so i don't really understand why it's called injection?!?!
Nikita Shilnikov
@flash-gordon
Aug 18 2016 08:56
first of all, you can register a block, and the code you place there can do anything. Every time you create an object this block will be evaluated
Nick Sutterer
@apotonick
Aug 18 2016 08:57
yeah i know, and that's all great stuff, but again, the created ruby code when doing include ..[..] could also generate a getter method for you which simply instantiates the object from the container, so why is it called auto-inject?
Nikita Shilnikov
@flash-gordon
Aug 18 2016 08:58
also you can pass your values into the constructor, like MyClassWithFooDependency.new(foo: my_dep) instead of MyClassWithFooDependency.new, this way the container won't be touched
Nick Sutterer
@apotonick
Aug 18 2016 08:58
yeah, that's an injection!
so the include ... does provide that logic automatically?
Nikita Shilnikov
@flash-gordon
Aug 18 2016 08:59
yes
Nick Sutterer
@apotonick
Aug 18 2016 09:03
hm... i find the term auto-inject a bit confusing, although it's ok since it "injects" in the constructor automatically. i would've understood better if it's called auto-builder or something. injection to me means something dynamic, but auto-inject is a static configuration, isn't it?
Nikita Shilnikov
@flash-gordon
Aug 18 2016 09:08
@apotonick let's just break it down. Under the hood auto-inject builds three things: class-level new method, instance-level initialize, and instance readers/getters. new lazily extracts dependencies from the container (as I said you can pass your own) and passes them to the constructor, initialize assigns obtained values to instance variables, ... oh, that's all. There is some stuff for dealing with inheritance but it's not relevant
Nick Sutterer
@apotonick
Aug 18 2016 09:13
ok, very cool, thanks @flash-gordon
Nikita Shilnikov
@flash-gordon
Aug 18 2016 09:17
np :)
Nick Sutterer
@apotonick
Aug 18 2016 09:21
@flash-gordon reason i'm asking so much is i make auto-inject available in TRB operations (actually, everywhere)
one more thing: the auto-inject is not meant for runtime parameters like current_user ?!
Piotr Solnica
@solnic
Aug 18 2016 09:26
@apotonick yeah we use DI for composing objects that receive their context as args in call (typically)
so ie current_user is passed to call rather than constructor
there are cases where it’s different though, ie dry-v’s schemas have context as their state (the option feature)
Nick Sutterer
@apotonick
Aug 18 2016 09:28
but i can still use auto-inject together with dynamic arguments not treated by auto-inject, @solnic ?
like Op.new(auto: 1, inject: 2, current_user: 3) ?
Piotr Solnica
@solnic
Aug 18 2016 09:28
IIRC it’s not possible as we use kwargs so all args must be always passed in
Nick Sutterer
@apotonick
Aug 18 2016 09:28
the first two being "covered" by the dry injection ?
hm, that's not good :/
Piotr Solnica
@solnic
Aug 18 2016 09:29
so current_user would always have to present, but if that’s the case then yeah, it’s gonna work
well, it is good as it’s not possible to instantiate an object with nil as current_user
Nick Sutterer
@apotonick
Aug 18 2016 09:29
i could simpy introduce a always-present :params object for the "dynamic" options
Piotr Solnica
@solnic
Aug 18 2016 09:30
I mean there are ways to make it work, you can always override .new and call super :)
Nick Sutterer
@apotonick
Aug 18 2016 09:30
can i say "do auto-inject for :arg and :bla but let me take care of :params" ?
Piotr Solnica
@solnic
Aug 18 2016 09:30
nope
Nick Sutterer
@apotonick
Aug 18 2016 09:31
reasoning?
Piotr Solnica
@solnic
Aug 18 2016 09:31
nobody implemented this :P
Nikita Shilnikov
@flash-gordon
Aug 18 2016 09:31
auto-inject will leave all extra kwargs untouched
Nick Sutterer
@apotonick
Aug 18 2016 09:31
because that way i could allow dry-auto-inject in operations (and contracts, and representers), but still keep our existing API
so it will work, @solnic @flash-gordon ?
Nikita Shilnikov
@flash-gordon
Aug 18 2016 09:32
yes
Nick Sutterer
@apotonick
Aug 18 2016 09:32
maybe i should just go implement it haha :joy:
Piotr Solnica
@solnic
Aug 18 2016 09:32
@flash-gordon ah so include Import[:foo, :bar] and then new(baz: ‘haha’) will work?
Nick Sutterer
@apotonick
Aug 18 2016 09:32
but that will be cool once it works, you can then auto-inject repositories and what not into the operation. this will be extremely cool to inject contracts or callback objects, too, with a "well-established" pattern from dry
Nikita Shilnikov
@flash-gordon
Aug 18 2016 09:32
yes :)
Piotr Solnica
@solnic
Aug 18 2016 09:32
ok so it’s all good @apotonick
Nick Sutterer
@apotonick
Aug 18 2016 09:32
hahaha
Piotr Solnica
@solnic
Aug 18 2016 09:32
:)
Nick Sutterer
@apotonick
Aug 18 2016 09:33
perfect! :tada:
Nikita Shilnikov
@flash-gordon
Aug 18 2016 09:36
@apotonick but don't forget to call super in intialize to invoke auto-inject's assignments
Nick Sutterer
@apotonick
Aug 18 2016 09:37
i would never forget that! *duck*
@flash-gordon like this: apotonick/trailblazer#133
Nikita Shilnikov
@flash-gordon
Aug 18 2016 09:43
:+1:
Piotr Solnica
@solnic
Aug 18 2016 09:45
@flash-gordon would you be interested in looking into rom-support and ways how we could kill this library through extracting things into dry-* ?
as in, in collaboration with me :)
Nikita Shilnikov
@flash-gordon
Aug 18 2016 09:46
@solnic sure, as soon as you tell me what to do :laughing:
Piotr Solnica
@solnic
Aug 18 2016 09:47
@flash-gordon rom-support is mostly 3 things 1) enumerable/array decorators (used in rom/memory/csv/yaml and similar) 2) deprecation APIs 3) auto-curry API
oh and I recently added 4th one - ROM::Cache
so I basically see all these things as some dry-*
no idea how to organize it though
enum/array stuff could be moved back to rom core I suppose
oh and there’s also class_macros and options but we might be able to simply use dry-initializer for options if we could make it compatible
and class_macros could be moved back to rom core
Nikita Shilnikov
@flash-gordon
Aug 18 2016 09:55
@solnic something completely different, would you mind if I add constrained? predicate in dry-t?
Nick Sutterer
@apotonick
Aug 18 2016 09:56
what do the array decorators do, @solnic ?
Piotr Solnica
@solnic
Aug 18 2016 09:57
@flash-gordon sounds good, it would actually be useful in dry-v :)
Nikita Shilnikov
@flash-gordon
Aug 18 2016 09:57
yeah, the reason why I'm doing it is because I tried to use custom types with dry-v
Piotr Solnica
@solnic
Aug 18 2016 09:58
@apotonick we use enum/array decoration for proxying methods from relations down to adapter’s datasets, in case of primitive adapters like rom-memory or rom-csv the underlying dataset is just an array, so we build things on top of it. ie memory adapter’s datasets expose apis like restrict limit etc. that just use array’s API
Nick Sutterer
@apotonick
Aug 18 2016 09:58
ah, cool!
Piotr Solnica
@solnic
Aug 18 2016 09:59
this is basically to be able to proxy methods down to the array while maintaining original class so ie ROM::Memory::Dataset decorates an array, and when you call #select on it, it will still return Dataset object rather than an Array
it’s a common pattern in the land of database libs, such a shame Ruby doesn’t provide that OOTB
Nick Sutterer
@apotonick
Aug 18 2016 10:05
ah ok, now i fully understand
so glad you're taking care of the persistence layer :joy:
Nick Sutterer
@apotonick
Aug 18 2016 10:11
@flash-gordon the auto_inject "paradigm" is to always have one hash for #new, correct?
Piotr Solnica
@solnic
Aug 18 2016 10:16
@apotonick yes, I’m a masochist O_o
Vladimir Dralo
@vladra
Aug 18 2016 10:40
hi all. I have question - how to correctly use dry-system if I'm inheriting from class which has initialise with some arguments?
Piotr Solnica
@solnic
Aug 18 2016 10:41
@vladra if you have a custom initializer and don’t need DI there then just don’t use it with the injector mixin, it’s not a requirement for dry-system
@vladra could you tell me more about this class? what kind of args does it accept?
we gotta make it clear in the docs that the injector mixin is a convenience and not a requirement
Vladimir Dralo
@vladra
Aug 18 2016 10:43
@solnic It's hanami view actually. It receives 2 arguments by default
Piotr Solnica
@solnic
Aug 18 2016 10:43
@vladra what args?
Vladimir Dralo
@vladra
Aug 18 2016 10:44
@solnic I think template and params, need to check exactly. I mean it's hanami method definition. But I have views which of course inherits from hanami view, and I'm confused how to use DI in this case
Piotr Solnica
@solnic
Aug 18 2016 10:47
@vladra hanami view is controlled by hanami, if you want to inject additional args then it’s gonna be tricky I think, esp that it’s a splat list of args not kwargs
we could look into making it work though…
best to ask Luca first
Vladimir Dralo
@vladra
Aug 18 2016 10:50
@solnic got it. so it seems I will need either override initialize or just not use DI in the view
Piotr Solnica
@solnic
Aug 18 2016 10:51
@vladra I think it would be really nice if we could make hanami-view work with DI assuming view objects are meant to be used like that
Vladimir Dralo
@vladra
Aug 18 2016 10:54
@solnic but in general, is there way to make dry system DI work while inheriting from some class with initialize predefined? using keyword arguments for example? not related to hanami for example
Piotr Solnica
@solnic
Aug 18 2016 10:58
@vladra not sure tbh, @timriley @flash-gordon ^^ you folks remember if this is supported already??
seems like there’s an assumption that super’s constructor doesn’t accept any args https://github.com/dry-rb/dry-auto_inject/blob/master/lib/dry/auto_inject/strategies/kwargs.rb#L39
I might be reading it wrong though, needs some investigation
Vladimir Dralo
@vladra
Aug 18 2016 11:06

From what I understood yesterday, it is in case super method doesnt have parameters:
https://github.com/dry-rb/dry-auto_inject/blob/master/lib/dry/auto_inject/strategies/kwargs.rb#L25

But I was mainly checking args strategy. And it looks like this line should cover my case:
https://github.com/dry-rb/dry-auto_inject/blob/master/lib/dry/auto_inject/strategies/args.rb#L41

So I was wondering maybe I'm doing something wrong

Nikita Shilnikov
@flash-gordon
Aug 18 2016 11:08
@apotonick re hash in new, auto-inject supports other strategies, but it's tricky. Using kwargs, ie one hash, is more predictable, otherwise passing sequential arguments as dependencies is cumbersome, believe me. And yes, you cannot mix args + kwargs
Tim Riley
@timriley
Aug 18 2016 11:09
I think something like this might be possible with kwargs but I'd need to double check. I can look tomorrow.
Nikita Shilnikov
@flash-gordon
Aug 18 2016 11:15
@vladra auto-inject assumes that your dependencies come first, and hanami passes template + locals first, tldr, I'm afraid this won't work. But we can try to support args in kwargs strategy, or mb add another strategy, not sure /cc @timriley
Nick Sutterer
@apotonick
Aug 18 2016 12:35
so, the auto-inject... i understand when you test, you can change the container constant beforehand, but how does that work for a component that comes in a gem? @solnic @flash-gordon ? because the dependency is hard-wired into the component?
Nikita Shilnikov
@flash-gordon
Aug 18 2016 12:41
@apotonick you need to access the container before the component was created and stub the dependency or create the component manually and inject the dependency by hand, there are no other option as far as I can tell
Nick Sutterer
@apotonick
Aug 18 2016 12:43
and from gems?
Nikita Shilnikov
@flash-gordon
Aug 18 2016 12:45
well, a gem can give a container and postpone initialization
Nick Sutterer
@apotonick
Aug 18 2016 12:47
can you make an example?
for example, what if a gem component (e.g. an operation) needs parts of the application? how would you specify that?
and the gem doesn't know the container name
Nikita Shilnikov
@flash-gordon
Aug 18 2016 12:50
ah, I see what you mean
dunno, not sure if it will play nice atm
Nick Sutterer
@apotonick
Aug 18 2016 12:53
hm, that's my thought, too. what is the plan about this? because this will be a problem, when gems need dependencies but don't know container names. i am not too sure if i like this static controller include at all, tbh
i can see how it makes it super simple to share dependencies, and it's way better than just globals, but it's still a global i have to hard-code into my components. is that desired?
Nick Sutterer
@apotonick
Aug 18 2016 13:04
@flash-gordon when i include an auto_inject module, it overrides new. what's the strategy to change that method, again? because we want 2 args, not just one (for now), and i can't override it in every single operation. what's the suggested strategy?
Andy Holland
@AMHOL
Aug 18 2016 13:06
@apotonick usually IoC will leverage interfaces and reflection to resolve dependencies from a container, so you bind an implementation to an interface in a container and it gets resolved using the interface you bind it to as its key, obviously we can't do that in Ruby
That way a class can be completely stand-alone and have no knowledge that it's being used in the context of IoC
But I definitely thing having the static injection include is 1M times better than hard-coded global constants and a class having knowledge of how to construct its dependencies
Also it's not a hard dependency as the collaborators can be overloaded in the constructor
Nikita Shilnikov
@flash-gordon
Aug 18 2016 13:08
@apotonick that's tricky a bit, you want to pass something like new(my_arg, kwarg_deps)?
Andy Holland
@AMHOL
Aug 18 2016 13:09
If you're talking about an application providing a container and a gem making use of dependencies from that container, just make the container a gem configuration option
Then the gem doesn't need to know the name of the container, it just has access to the container via configuration
Nick Sutterer
@apotonick
Aug 18 2016 13:09
@AMHOL agreed on the defined dependencies, it's way better of course. wasn't criticizing that. but i have a feeling that it can get messy with 3rd-party components and containers
what would that look like?
@flash-gordon exactly. is that tricky?
Andy Holland
@AMHOL
Aug 18 2016 13:10
Lemme have a mess about and I'll get back to you on that soon
Nick Sutterer
@apotonick
Aug 18 2016 13:10
the thing is: i can't (and don't want to until i see how the auto_inject helps) change the operation API right now
Nikita Shilnikov
@flash-gordon
Aug 18 2016 13:12
@apotonick yeah, we don't support args + kwargs mix right now: https://github.com/dry-rb/dry-auto_inject/blob/master/lib/dry/auto_inject/strategies/kwargs.rb#L12 though we could change kwargs strategy or build a new one
@apotonick could you raise an issue?
Nick Sutterer
@apotonick
Aug 18 2016 13:16
@flash-gordon is that really complicated to change?
Nikita Shilnikov
@flash-gordon
Aug 18 2016 13:17
@apotonick it could be because of inheritance
Nick Sutterer
@apotonick
Aug 18 2016 13:19
really?
Nikita Shilnikov
@flash-gordon
Aug 18 2016 13:23
@apotonick yeah, just think of it, you need to create two methods (new + initialize) that have to know about existing methods, know their arity to make proper super calls and compile the correct/valid code
Nick Sutterer
@apotonick
Aug 18 2016 13:23
what's the finalize! method, @AMHOL ? thanks BTW
Nikita Shilnikov
@flash-gordon
Aug 18 2016 13:23
it took a while implementing what we already have
Andy Holland
@AMHOL
Aug 18 2016 13:24
@apotonick the finalize! method would be called post-configuration and would require anything that uses injection
Otherwise include MyGem.inject[:stuff] will be called with a nil container
Nikita Shilnikov
@flash-gordon
Aug 18 2016 13:25
also remember that you can inject dependencies multiple times in the same class, not the same dependencies, just several injections
plus inheritance
Nick Sutterer
@apotonick
Aug 18 2016 13:35
and you guys are a 100% confident that hard-coded constants, loading order, finalize, and const_set, etc. is a good idea for dependency sharing? i am happy someone works on this, but i am a bit skeptical how this works out in projects with unexperienced devs... what's your opinions on that?
Andy Holland
@AMHOL
Aug 18 2016 13:38
@apotonick const_set was just for the example
@apotonick re: include Inject[:some_dep] as a hard-coded constant, yes, I'm confident that it's better than the alternatives in Ruby
Nick Sutterer
@apotonick
Aug 18 2016 13:40
the alternatives are?
  1. access random constants and hope it won't break
  2. rely on injected deps, as in hoping the user will pass them in
  3. same as 2. but with a argument check as in a typed language
Andy Holland
@AMHOL
Aug 18 2016 13:40
i.e. hard-coded constants + leaking knowledge of how to construct a class into other classes
Or global construction with dependency passing
@apotonick constants are globals
Nick Sutterer
@apotonick
Aug 18 2016 13:41
i can totally see how it makes it simpler but for some reasons this static constant bugs me
yeah but the container name is also a global
it's only one global, though
Andy Holland
@AMHOL
Aug 18 2016 13:41
Yeah, but it's 1 global vs 100
And it's a soft dependency
Nick Sutterer
@apotonick
Aug 18 2016 13:42
why soft?
Andy Holland
@AMHOL
Aug 18 2016 13:42
It's a global that can provide nothing if you want it to
Nick Sutterer
@apotonick
Aug 18 2016 13:42
valid point.
Andy Holland
@AMHOL
Aug 18 2016 13:42
So you can still new up with explicit arguments
Nick Sutterer
@apotonick
Aug 18 2016 13:43
it's not that i'm against it or anything. it's just that the container constant felt/feels a bit like trouble
i'm glad i finally understood how it's supposed to work
Andy Holland
@AMHOL
Aug 18 2016 13:43
Yeah, in an ideal world it wouldn't be necessary
Nick Sutterer
@apotonick
Aug 18 2016 13:43
it's a bit hard to understand that auto_inject and manual inject are similar but not the same. can i please contribute docs?
Andy Holland
@AMHOL
Aug 18 2016 13:43
But it's the lesser of 10 evils
much lesser
:p
@apotonick that would be awesome :D
Nick Sutterer
@apotonick
Aug 18 2016 13:44
what i fear is that people will now hardcode those dependencies in every component instead of carefully passing dependencies in manually, because they think that the auto_inject is "cleaner"
e.g. sometimes a view shouldn't even know about a repository, but since "i use auto_inject, it's ok"
know what i mean?
so @flash-gordon you say the new(our_stuff, kws) is hard to implement? can i help?
couldn't that be easily solved by something as follows:
class Operation
  include Dry::AutoInject::MultipleArgs
Andy Holland
@AMHOL
Aug 18 2016 13:47
@apotonick IMO a view should never know about a repo
Nick Sutterer
@apotonick
Aug 18 2016 13:48
@AMHOL yeah, i agree, but someone asked just that a few hours ago, and that's when i realized that this might lead to an overuse of dependency sharing
because now, with auto_inject, it's so nice and easy and explicit
Nikita Shilnikov
@flash-gordon
Aug 18 2016 13:48
@apotonick oh, you defo can try :) but we should ask @timriley first if it should be a separate strategy or not, I don't have a preference personally
at least having many strategies is 100% ok
Nick Sutterer
@apotonick
Aug 18 2016 13:49
@flash-gordon @timriley to play with it, i could simply re-override new and call super, couldn't i?
Andy Holland
@AMHOL
Aug 18 2016 13:49
@apotonick re: people using it like that, there's nothing you can really do to stop it other than warning people about it
Nick Sutterer
@apotonick
Aug 18 2016 13:50
@AMHOL haha, i know man, i've written one or two gems already ;)
Andy Holland
@AMHOL
Aug 18 2016 13:50
haha
Nick Sutterer
@apotonick
Aug 18 2016 13:51
however, it must be stated everywhere that this easy-to-use mechanism is not meant as a dependency carousel
the reason i keep annoying you guys here is, i really really want to work towards a standard with dependencies, and TRB and dry must work together seamlessly
Nikita Shilnikov
@flash-gordon
Aug 18 2016 13:51
@apotonick this won't work, because you cannot override new, it's injected via a separate module, you can add a method on top of it, but this won't help. It's hard to explain, just try it :)
Nick Sutterer
@apotonick
Aug 18 2016 13:52
but can't i call super from another injected module?
Nikita Shilnikov
@flash-gordon
Aug 18 2016 13:54
you can, but you can't pass your arguments there, because auto-inject can pass them through itself
when I say it's hard, I mean it, because I don't know how to describe how it works without some pictures :)
ruby's inheritance is tough sometimes
Nick Sutterer
@apotonick
Aug 18 2016 13:55
oh yeah, especially when it comes to new, i've avoided it so far
the reason you override new is because that's where you access the container and inject? @flash-gordon
Nikita Shilnikov
@flash-gordon
Aug 18 2016 13:56
exactly
Nick Sutterer
@apotonick
Aug 18 2016 13:56
can you point me to the source?
maybe i can hack my way around. i need to use the next 2 days to play with it and prototype a bit
via a closure
Nick Sutterer
@apotonick
Aug 18 2016 14:01
gotcha, thanks
so the initialize(container) is the "problem"
i'm trying to think of a way to avoid another argument, but it all makes the op call very clumsy, @flash-gordon
Nick Sutterer
@apotonick
Aug 18 2016 14:06
BTW, do we all agree that kwargs are the way to go, @flash-gordon @AMHOL @solnic ?
Andy Holland
@AMHOL
Aug 18 2016 14:07
@apotonick yep
Luca Guidi
@jodosha
Aug 18 2016 14:07
@apotonick I think so :smile:
Andy Holland
@AMHOL
Aug 18 2016 14:07
I think it's much better than inferring the accessor name from the container key
Nick Sutterer
@apotonick
Aug 18 2016 14:09
hhaha hi @jodosha ! i will hang out with you, simone, and my dad sept 8 in roma, in case you didn't know
@AMHOL in the dependencies example for sure, i would never do that without kws. i meant in general, for top-level APIs that might receive a bunch of args
Luca Guidi
@jodosha
Aug 18 2016 14:11
@apotonick Wow, big news :it: :heart: - Better to get back in Rome by then :wink:
Piotr Solnica
@solnic
Aug 18 2016 14:11
speaking of which, I’m gonna be in Rome in November
first in Florence then Rome
Andy Holland
@AMHOL
Aug 18 2016 14:12
@apotonick I prefer kwargs for arguments with defaults, don't really mind otherwise
Luca Guidi
@jodosha
Aug 18 2016 14:12
@solnic WOW amazing! Are you going to speak at RubyDay?
Piotr Solnica
@solnic
Aug 18 2016 14:12
yes, they invited me :)
http://www.rubyday.it <= good company :)
Luca Guidi
@jodosha
Aug 18 2016 14:12
Great! I'll be at the conf too
Piotr Solnica
@solnic
Aug 18 2016 14:12
that’s even better!
Luca Guidi
@jodosha
Aug 18 2016 14:13
Oh I missed that lineup, great!
what's your topic?
Piotr Solnica
@solnic
Aug 18 2016 14:14
undecided
they have my proposal but they are still discussing it
title is “Can we still innovate?”
Nick Sutterer
@apotonick
Aug 18 2016 14:14
@jodosha www...w.wait, where will you be in sept?
love the title, @solnic
Piotr Solnica
@solnic
Aug 18 2016 14:15
it might be the keynote if they pick me up
Nick Sutterer
@apotonick
Aug 18 2016 14:15
you deserve it
Luca Guidi
@jodosha
Aug 18 2016 14:16
@apotonick I'm outside the city for the summer and we're considering when to get back. So now we have a good reason to get back by Sept 8.
Nick Sutterer
@apotonick
Aug 18 2016 14:16
hahaha that would be cool @jodosha - i will go hiking with my dad for the following week
you're free to join!
Luca Guidi
@jodosha
Aug 18 2016 14:17
@apotonick Where are you going to hike?
Nick Sutterer
@apotonick
Aug 18 2016 14:17
abruzzo!!!
Luca Guidi
@jodosha
Aug 18 2016 14:17
That makes sense. :)
Nick Sutterer
@apotonick
Aug 18 2016 14:18
he still wants to convert the website into a ruby on rails app, which i kindly discouraged ;)
Luca Guidi
@jodosha
Aug 18 2016 14:19
hahhahahaha
so you're joining him just for a part of the route?
Nick Sutterer
@apotonick
Aug 18 2016 14:22
yeah, of course, i'm a nerd
Luca Guidi
@jodosha
Aug 18 2016 14:23
Now I recognize you, Nick!
Andy Holland
@AMHOL
Aug 18 2016 14:49
:laughing:
Joshua Wilcox
@joshuaswilcox
Aug 18 2016 15:54
Hello, I am trying to have optional datetime in a Dry::Types::Struct with attribute :foo, Types::DateTime.optional but when I send in a hash with either foo empty or foo blank, it fails with either "must be filled" or "is missing", what am I missing here?
Piotr Solnica
@solnic
Aug 18 2016 15:56
@joshuaswilcox optional means either nil or DateTime
Joshua Wilcox
@joshuaswilcox
Aug 18 2016 15:56
so {"foo": null} then? that doesn't work
Piotr Solnica
@solnic
Aug 18 2016 15:57
keys must be symbols
Joshua Wilcox
@joshuaswilcox
Aug 18 2016 15:57
well that was json, so it get converted to keys
ah shoot, sorry i had a different validation layer getting in the way, derp
mixing up dry-validation and dry-types
Andrew Kozin
@nepalez
Aug 18 2016 20:35
@solnic ^^ that's what I told about ;)
Tim Riley
@timriley
Aug 18 2016 23:28
@apotonick @flash-gordon @AMHOL Reading through the conversation earlier, I feel like dry-auto_inject isn’t really suitable for a gem author wanting to provide base classes that application authors should inherit from.
IMO the best thing to do would be to make those base classes DI-friendly so that the application author could choose to use dry-auto_inject if they wanted.
# In the gem

module Trailblazer
  class Operation
    attr_reader :policy
    attr_reader :something_else

    def initialize(policy:, something_else:)
      @policy = policy
      @something_else = something_else
    end

    def some_other_base_method(input)
      # do something with `policy`
      # do something with `something_else`
    end
  end
end

# In the application, where the developer has chosen to use dry-system

module MyApp
  class Container < Dry::System::Container
  end

  Inject = Container.injector

  class MyOperation < Trailblazer::Operation
    include MyApp::Inject[
      policy: "my_policy",
      something_else: "foo.bar.my_other_thing"
    ]
  end
end
Andy Holland
@AMHOL
Aug 18 2016 23:31
:+1:
Tim Riley
@timriley
Aug 18 2016 23:31
By designing the gem’s base classes so they use constructor-based DI (using keyword args for clarity), if then becomes an easy choice for someone to use dry-auto_inject with their own application’s subclasses.
If you try and somehow build dry-auto_inject right into the gem’s code, then you’re basically forcing everyone to deal with containers, etc.
which makes the code less flexible.
Building around a container might make sense for rom, for example, because it is designed to be a self-contained ecosystem that gets loaded into an application, but it doesn’t make sense everywhere