These are chat archives for dry-rb/chat

24th
Jan 2018
Kelsey Judson
@kj
Jan 24 2018 09:16
I'm having an issue with dry-auto_inject when the last argument passed to .new responds to #to_hash, and I wondered if anyone might know of a solution, or perhaps if it can be fixed in the gem itself? https://gist.github.com/kj/35af5c95c804b760c147ef57da8f0871
Tim Riley
@timriley
Jan 24 2018 09:20
@kj Yep, this kind of destructuring is expected and annoyingly hard to avoid if your object implements the #to_hash implicit hash conversion method
Is this a class you control?
Ah, it’s Hanami::Entity
Kelsey Judson
@kj
Jan 24 2018 09:22
The #to_hash class for me is Hanami::Entity, the one I'm passing it to is mine.
Tim Riley
@timriley
Jan 24 2018 09:22
I think it’d be better if they implement #to_hash, tbh
#to_h is the more appropriate hash conversion method for those to implement, IMO
I know this doesn’t immediately help you, sorry
Kelsey Judson
@kj
Jan 24 2018 09:23
Yeah I was thinking that too. It's really only that one class for me right now, but I might ask the Hanami people what they think.
Just wondered if you were aware of it, and if it could be fixed, but I couldn't think of a way around it myself!
Tim Riley
@timriley
Jan 24 2018 09:24
Yeah, all I can think of right now is opening up Hanami::Entity and undef-ing to_hash
It’s only implemented as an alias, so I have a feeling it may not actually be necessary, but instead a convenience that they might’ve thought was useful at one point
Kelsey Judson
@kj
Jan 24 2018 09:25
Hopefully! I'll give it a go. Thanks :).
Tim Riley
@timriley
Jan 24 2018 09:26
This’d be good to bring up with the Hanami team too, I think
Kelsey Judson
@kj
Jan 24 2018 09:27
Will do.
Tim Riley
@timriley
Jan 24 2018 09:28
Here’s when it was introduced: hanami/model@26c17eb
Based on this, I think it could be safely removed, at least within your app.
I might ask them about why it’s there
Kelsey Judson
@kj
Jan 24 2018 09:29
You may be able to explain it better than me.
I only learned about the implicit/explicit conversion methods today. Sometimes it's good running into issues like this and being forced to learn more about how it works!
Tim Riley
@timriley
Jan 24 2018 09:31
Yeah, they’re a really interesting (and good to know!) part of Ruby
Tim Riley
@timriley
Jan 24 2018 09:36
Thanks for taking the time to do a nice writeup, btw, @kj
Kelsey Judson
@kj
Jan 24 2018 09:39
No worries! Easier to get help that way!
(and a good reference for myself)
Tim Riley
@timriley
Jan 24 2018 09:44
@kj BTW, why are you trying to auto-inject an entity object?
That’s not really an “abstract dependency”, which is why auto-injection is meant to help with
Kelsey Judson
@kj
Jan 24 2018 09:45
@timriley No, it's just passed as an argument to another class.
Tim Riley
@timriley
Jan 24 2018 09:46
so you’re still passing it when you’re initializing an object that has an auto injector moxed in?
Kelsey Judson
@kj
Jan 24 2018 09:46
Like in my gist, WithToHash would be the entity.
Yeah, I did read that this is not desirable?
Tim Riley
@timriley
Jan 24 2018 09:46
In your case I would pass the entity to #call
This is generally how we design these objects
abstract dependencies are injected, get saved in state
other args go to call, which doesn’t touch the state at all
this allows your object to be called multiple times with different args and everything still works
And by following this arrangement you completely avoid the issue that brought you here today
Kelsey Judson
@kj
Jan 24 2018 09:50
Ah I see. Yeah I have been trying to design my classes roughly like that. In one or two cases it feels 'convenient' to have some extra state passed in through #initialize. For example, when the entity is an object I'm acting upon for all future calls using that instance (with varying arguments to #call).
Tim Riley
@timriley
Jan 24 2018 09:51
OK, in this case just make it a named kwarg
def initialize(my_entity:, **kwargs)
that’ll stop it from being destructured
but also reconsider doing this, still :P
Kelsey Judson
@kj
Jan 24 2018 09:52
Maybe I'm just asking for trouble mixing it up like this, I'm not really sure. I've been trying to figure out how I want to approach this for a few days now.
Ah, that's an option!
Tim Riley
@timriley
Jan 24 2018 09:53
I feel you should just pass the same thing to #call every time you need it
this is not a huge burden and it allows you to keep a really clear and consistent class design
dependencies go into state via #initialize, data goes into #call and just passes through
Kelsey Judson
@kj
Jan 24 2018 09:54
Yeah, consistency and clear rules is what I'm after here. I think it's one of those situations where my past experience is telling me to do one thing, and I'm having trouble completely letting it go.
Tim Riley
@timriley
Jan 24 2018 09:55
heh
Kelsey Judson
@kj
Jan 24 2018 09:56
When you're passing this state to #call, would you ever set instance variables, to avoid passing state all around as args to other methods (I think this feels dirty)?
Tim Riley
@timriley
Jan 24 2018 09:57
no, no, never do that
#call does not mutate state in any way
don’t assign or change ivars
Again, passing args explicitly to private methods is fine, and it helps maintain the clear class design principle
Kelsey Judson
@kj
Jan 24 2018 09:58
I think this is what keeps drawing me back to passing state in #initialize. Just the convenience of having it all there and available at all times.
Tim Riley
@timriley
Jan 24 2018 09:58
As a wise person once said, let it go
:P
Kelsey Judson
@kj
Jan 24 2018 09:58
Haha, yeah that's probably true!
Tim Riley
@timriley
Jan 24 2018 09:58
If you’re having that many private methods, your class is probably doing too much
Kelsey Judson
@kj
Jan 24 2018 10:00
Yeah, I don't tend to have too many, so I'm probably complaining about nothing.
Thanks for all your help, I have a lot of thinking to do ;).
Tim Riley
@timriley
Jan 24 2018 10:02
np!