<havenwood>
mooff: That ^ makes a Digest::MD5::Mixing module you can include with all the class methods Digest::MD5 defines.
<havenwood>
Digest::MD5::Mixin*
davidw_ has quit [Ping timeout: 240 seconds]
<mooff>
havenwood: interesting. i didn't think that would be possible, as define_method is strict about classes matching when you give it a Method!
<weaksauce>
do you program much anymore for your job havenwood ?
<mooff>
ah. the trick is coming from Method#to_proc
<mooff>
it's cheating a little, but cool nonetheless
jpn has joined #ruby
markong has quit [Ping timeout: 276 seconds]
jpn has quit [Ping timeout: 246 seconds]
constxd has quit [Ping timeout: 248 seconds]
jl- has joined #ruby
jl- has quit [Ping timeout: 272 seconds]
Ziyan has joined #ruby
jpn has joined #ruby
jpn has quit [Ping timeout: 240 seconds]
jl- has joined #ruby
factor has quit [Read error: Connection reset by peer]
jl- has quit [Ping timeout: 256 seconds]
Al2O3 has quit [Ping timeout: 272 seconds]
Al2O3 has joined #ruby
_ixti_ has joined #ruby
ixti has quit [Read error: Connection reset by peer]
jpn has joined #ruby
_ixti_ has quit [Remote host closed the connection]
_ixti_ has joined #ruby
jpn has quit [Ping timeout: 264 seconds]
<ox1eef_>
well... if you can do it without C, in my view that's better.
<ox1eef_>
C should be a last resort.
jpn has joined #ruby
jpn has quit [Ping timeout: 246 seconds]
<havenwood>
weaksauce: I do think about code a lot as part of my job, but yeah, most of the time I'm not writing code.
<havenwood>
Sometimes I'll code a bunch for a stint for various reasons. It depends.
<havenwood>
mooff: I don't know that I even see it as cheating, since it's like using a proc for a block. Here it's a lambda, but methods are naturally lambdas. Yeah, there's no way to unbind and rebind across classes even without Fiddle or C.
jl- has joined #ruby
jl- has quit [Ping timeout: 272 seconds]
<mooff>
Method#to_proc seems to act like def to_proc() = -> *args, &blk { call(*args, &blk) }
<mooff>
i.e. like it returns a lambda that just calls call on itself
<mooff>
but that's different from including a module, where calling e.g. foo.bar will run bar with foo as the receiver
jpn has joined #ruby
jpn has quit [Ping timeout: 256 seconds]
dionysus69 has joined #ruby
rvalue has quit [Read error: Connection reset by peer]
<havenwood>
mooff: Ah, gotcha. I was assuming they were functions and you may want to use the receiver. OO...
<havenwood>
mooff: In this case though, they are functions and you don't want to use the receiver, right?
_ixti_ has quit [Remote host closed the connection]
_ixti_ has joined #ruby
Ziyan has joined #ruby
<havenwood>
My solutions was just for class methods. I wasn't trying to make instance method mixins there ^
<havenwood>
I explicitly was trying not to tie it to the receiver.
<havenwood>
I guess it depends whether you're trying to mixin classes generally, which I would assume would be instance methods, or whether you want to expose class methods, which operate like module functions.
<havenwood>
The goal above seemed like the latter to me, but both are fun.
Ziyan_ has joined #ruby
jl- has joined #ruby
Ziyan has quit [Ping timeout: 260 seconds]
jl- has quit [Ping timeout: 276 seconds]
jpn has joined #ruby
jpn has quit [Ping timeout: 246 seconds]
gr33n7007h has quit [Quit: WeeChat 3.5]
protektwar has joined #ruby
protektwar has quit [Changing host]
protektwar has joined #ruby
wand has quit [Remote host closed the connection]
gr33n7007h has joined #ruby
<havenwood>
It would probably be better if Ruby had an explicit "I don't care about the receiver" `fn` or something along those lines, IMHO, since it's really preferred to signal if the receiver matters.
<havenwood>
I use `module_function` but it's a bit janky and no equivalent for classes.