Pattern matching alone is a huge feature and an absolute delight to use when the opportunity presents itself.
I’d love to see where Ractor goes but I worry it will remain niche, like with Refinements.
I’d love to see where Ractor goes but I worry it will remain niche, like with Refinements.
The pipe operator implementation proposal that they team came up with was wrong though and I'm glad they didn't do it. We don't need alternate syntax for `.`, we need ability to chain arguments together in a syntactically pleasant way in a functional style so we don't have to write `first(second(third(arg)))` we can write `arg |> third() |> second() |> first` which is much cleaner and reads left to right like it should
Would've been a bit more concise with method references, almost introduced in 2.7, but alas.
(But, well, people tend to want "something that looks like operator, preferably something that looks exactly like |>" and reject every other possibility)
That still wouldn't have solved passing additional args, so maybe { object.method_name(_1, args)} is the next best thing. Though it perceives non-atomic due to wrapping block.
```
first = ->(x){some code...}
second = ->(x){some code...}
third = ->(x){some code...}
(third >> second >> first).call(arg)
```
I agree it's not as clean as what you propose, but much better imo than traditional nested calls (and Haskell's `.`).
Ruby being a type 2 lisp is a fun one - creating a class and and a factory function with the same name, with argument forwarding:
class Animal; …; end
def Animal(…); Animal.new(…); end module HashExts
refine Hash do
def symbolize_values = transform_values { _1.to_sym }
end
end
module Test
using HashExts
def self.new_h = Hash.new
end
puts Test.new_h.symbolize_values
# => undefined method `symbolize_values' for {}:Hash (NoMethodError)As far as I know the teething issues around refinements are ironed out but they remain an obscurity.