Yes to all of that ^^ :)
@AMHOL reckon you could move that repo into your account?
so, i will simply use dry-initializer?
@timriley @AMHOL @solnic i am guessing dry-i plays with dry-auto_inject? the new operation will integrate seamlessly with your stuff, so we have the best of both worlds (for those who want it)
If you design allows for static dependencies/config to be passed into the initializer and then any "local", variable data to be passed into
#call or other methods, then you should be good, @apotonick
@timriley uhm, i make Op work with auto_inject, is that what you mean?
Use dry-initializer if you want that convenience, but you can also just build your own initialize methods by hand, either is fine :)
What I'm saying is that dry-initializer lets you build any sort of initializer you want. What determines compatibility with auto inject is the design choices you make, not the particular code you use to back that up.
I would suggest not using dry-initializer until at some point you really feel a need for it.
Because at least then you're not running the risk of conflating the tools and the class design.
the thing is, i don't want to rewrite dry-initializer, because that's what will happen :D
Yeah, fair enough, if you know you already need some convenience layer like that, go for it 👍🏼
@timriley we can just delete that repo TBH
@AMHOL you sure? I can go do it now if you like.
Yeah don't see why not the gem isn't alive anymore
Alrighty, bye bye repo :wave:
lol
dry-view actually feels more like dry-view_controller, at least in its current incarnation
well, the classes are the view controllers, the views are the templates
the gem could keep the same name
@flash-gordon could you ping me on things that touch the dry-types hash schema or dry-struct?
I don't need to approve everything and I'm not asking to be a guardian of that code
but I did put a decent amount of work into those and I use that code heavily so I do like knowing what was wrong with it before and what is changing