These are chat archives for dry-rb/chat

12th
Feb 2016
Pascal Betz
@pascalbetz
Feb 12 2016 10:06
would be interested in Bath Ruby. But it's not around the corner for me:-)
Andy Holland
@AMHOL
Feb 12 2016 13:41
Yeah, I guess it's not really a conference where people will travel that far, being in England rather than a tropical paradise somewhere :laughing:
Fran Worley
@fran-worley
Feb 12 2016 13:42
@AMHOL Hey!! We've had some good weather this year.... :laughing:
Andy Holland
@AMHOL
Feb 12 2016 13:43
:joy: I went out for lunch before and couldn't feel my fingers when I got back
Fran Worley
@fran-worley
Feb 12 2016 13:44
Well I didn't say it was nice at the moment...
Andy Holland
@AMHOL
Feb 12 2016 13:53
You know us Northerners, we like a good moan :p
Fran Worley
@fran-worley
Feb 12 2016 13:53
Now I feel bad... I'm moaning and only have to deal with the London climate :smile:
Jeremy Friesen
@jeremyf
Feb 12 2016 13:56
I’m looking at the auto-import mechanism from auto_inject and component; I’m wondering the plans for resolving keyword args? I’m curious in pushing this forward (as I’m preferring the use of keywords). (@AMHOL @solnic)?
Andy Holland
@AMHOL
Feb 12 2016 14:02
@jeremyf the plan is to add keyword support to dry-constructor and make use of that in dry-auto_inject, we haven't really discussed it beyond that, I was thinking of adding an interface like include Dry::Constructor::Kwargs(:response, :validator, :command) or something alike in dry-constructor then auto_inject could accept a hash argument, something like
include AutoInject[kwarg_key_1: 'container.key_1', kwarg_key_2: 'container.key_2']
Jeremy Friesen
@jeremyf
Feb 12 2016 14:04
@AMHOL That would be fantastic. I may have some time this morning/afternoon to push this out.
Andy Holland
@AMHOL
Feb 12 2016 14:04
@fran-worley Manchester and London are on par at the moment, so no need to feel bad :laughing:
@jeremyf that would be awesome, thanks for getting involved :smiley:
Jeremy Friesen
@jeremyf
Feb 12 2016 14:05
@AMHOL I’m not leveraging Dry::Constructor so the Dry::AutoInject would be where I’d be working.
@AMHOL I have some perhaps esoteric needs for the Kwargs constructor behavior and was poking around with that but didn’t want to proceed to far afield.
Andy Holland
@AMHOL
Feb 12 2016 14:06
That's cool, we can update it to make use of Dry::Constructor some other time :)
@jeremyf did you see dryrb/dry-constructor#1 ? Specifically this comment, I don't have much time free to work on dryrb stuff at the moment, but it's something I need to think about, I like the idea of composable behaviour for dry-constructor
Perhaps that would work out well for you too?
Jeremy Friesen
@jeremyf
Feb 12 2016 14:12
I think it could. However, I’m going to focus first on what appears to be aliasing for the named parameter;
include AutoInject[‘hello’, attribute_name: ‘container.key’]
Pascal Betz
@pascalbetz
Feb 12 2016 14:14
@solnic the "Guides" link on https://github.com/rom-rb/rom-mapper seems to be broken.
Piotr Solnica
@solnic
Feb 12 2016 14:16
@jeremyf it is a planned feature. I already added support for configurable constructors and positioned args and hashes are supported. kw args would be osm
Andy Holland
@AMHOL
Feb 12 2016 14:22
:+1:
Jeremy Friesen
@jeremyf
Feb 12 2016 14:27
Hmm. It would appear my convention runs contrary to the auto load
container.register(:form_builder) { Milan::FormBuilder.method(:new) }
(And now I get pulled into a nasty production change to make)
Piotr Solnica
@solnic
Feb 12 2016 14:40
aliasing is a planned feature, too
Jeremy Friesen
@jeremyf
Feb 12 2016 15:45
@solnic Would this align with the aliasing (I didn’t include tests just spitballing) jeremyf/dry-container@e4ad42a
Piotr Solnica
@solnic
Feb 12 2016 15:46
oh, I meant aliasing in auto_inject, not in the container, sorry!
no need to alias stuff in container I believe /c @AMHOL
Jeremy Friesen
@jeremyf
Feb 12 2016 15:47
No worries. Just a 5 minute speculation.
Will explore dry-auto_inject
Andy Holland
@AMHOL
Feb 12 2016 15:52
@solnic can't see any harm in it but I can't think of a need for it
Piotr Solnica
@solnic
Feb 12 2016 15:52
adding code is always “harm” in the sense of increased complexity :)
Andy Holland
@AMHOL
Feb 12 2016 15:53
:+1:
Piotr Solnica
@solnic
Feb 12 2016 15:53
@jeremyf I was thinking about sth like include Import.kwargs(foo: ‘core.stuff.foo_dep’, bar: ‘core.stuff.bar_dep’)
with Import.hash being an equivalent but using a hash, not kwargs
Jeremy Friesen
@jeremyf
Feb 12 2016 15:55
The question is should a Container allow for aliases? Or is that a concern for the Dependency Injection only?
Piotr Solnica
@solnic
Feb 12 2016 15:55
I don’t think it’s needed tbh
DI mechanism can handle that (in auto_inject)
Jeremy Friesen
@jeremyf
Feb 12 2016 15:55
Aliases are nice from a refactoring stand-point; But given the nature of the registry, I’d rather have a canonical and less "see also"
Piotr Solnica
@solnic
Feb 12 2016 15:56
I’d start with aliasing being handled at injection level and see what to do on container side when we have an actual use case for that
Jeremy Friesen
@jeremyf
Feb 12 2016 15:56
:+1:
Piotr Solnica
@solnic
Feb 12 2016 15:57
I’m very conservative when it comes to “oh it would be cool if X had Y” because even when I’m almost sure it would be cool indeed, I’d prefer to hold off and see an actual need for that (ie somebody shows up and says “I need X to have Y”) :)
otherwise things are piling up, development time increases, and we don’t even know if what we did is being used :D
Jeremy Friesen
@jeremyf
Feb 12 2016 15:59
:+1: