I wrote a gem with a C extension of `Proc#compose`: https://github.com/mooreniemi/proc_compose#usage What motivated me was `map f (map g xs) = map (f . g) xs`, and what I still don't understand (being a newbie to extending Ruby or und...why-capslock-though (Alexander Moore-Niemi)
to be precise, implies is a derived operator, not a core one. racket has this operator, as does eiffel, which supplies it to, afaik, help make design by contract easier (targeting assertions as a core responsibility of the language) ...why-capslock-though (Alexander Moore-Niemi)
I had posted some more code but remembered "send" doesn't apply yet! Sorry for my confusion. Any plans on indirect method access?why-capslock-though (Alexander Moore-Niemi)
Nobuyoshi Nakada wrote: > In general, the scope inside a method definition is different from outside. > ... So I was correct, in that `refine` invokes a different scope where the refinements aren't activated? Ok, cool. That's kind o...why-capslock-though (Alexander Moore-Niemi)
Here is an executable version of what I was roughing out above, I apologize for not vetting it beforehand to prevent confusion: ~~~ruby require 'active_support/core_ext' module A refine Time do def weekday self.strfti...why-capslock-though (Alexander Moore-Niemi)
Nobuyoshi Nakada wrote: > I can't get your point. > ... Yes, I mistakenly left out the "do" after `refine ActiveSupport::Time` (which should be `ActiveSupport::TimeWithZone`) and `refine Time`, with it the code does indeed work, and my...why-capslock-though (Alexander Moore-Niemi)
I doubt I am seeing a bug, but I was hoping someone could clarify for me the reason why I am seeing what I see. I tried pouring over the spec and wasn't quite able to pin it down. My use case of refinements is not the normal one, so t...why-capslock-though (Alexander Moore-Niemi)