ruby-core

Issue #19764 has been updated by rubyFeedback (robert heiler).


I do not have a particular strong opinion either way, largely because
I am using ruby more from an OOP point of view, so pattern matching,
strong (mandatory) types and so forth aren't quite the way how I use
ruby.

I did want to say something about style, though. The threadstarter
made this statement:

"in a more Ruby-like way that Rubyists are already learning and loving."

I believe that style, beauty and elegance is subjective. For instance,
to me personally - and I am sure others may agree or disagree - the above
may not be extremely "ruby-like" or elegant. So I believe reasoning 
primarily from a, mostly subjective, point of view will not be correct
at all times. People are different, so are their preferences; matz pointed
this out in the past. I believe this is one reason why ruby is fairly
flexible too, with the "more than one way to do something" philosophy
(and to some extent, syntax-wise).

In regards to syntax, I believe one thing that also should be discussed
is whether a new def-keyword should be added in general; and, if so, 
specifically for pattern matching. zverok did not make a suggestion for
this on the ruby issues tracker (I believe), so I would assume that for
now he only discussed it on the blog. From this context I would reason
that **an additional discussion should be whether new def-centric keywords
should be added (or not)** . We have "def", which python also uses, and I think most
will agree that this is short, succinct, and to the point; and we have
define_method() which may be used for meta-programming like functionality
(I use this in a few project with instance_eval or class_eval sometimes,
for instance, batch-generation of HTML colour keywords, such as "def steelblue"
where I did not want to write like 500x "def", so I just use define_method
instead). So this should be part of a discussion, whether "defp" is necessary
as a new keyword due to pattern matching needs. I am not sure this is the
case, but either way my point is that it should be discussed as well, no
matter the outcome.

Also, Dan0042 gave some "def" examples, but I think these are different
from "defp" examples. So that also seems a bit a separate discussion.

Perhaps MRI itself should stay somewhat more conservative. We had unusual
ideas in the past, e. g. evil.rb and shapechanging classes/objects. Perhaps
we could have "sub-type" dialects of ruby - not necessarily in MRI, but as
add-ons to the language itself directly (similar to evil.rb, such as a 
"functional" sub-project where all these ideas could be bundled; although
people can say that this could be a separate gem and perhaps it may be
bundled or not. The question then would be whether that should be made 
available for all ruby users to use or not. Not everyone uses pattern
matching, for instance.)

Last but not least, since zverok's blog mentioned it: it's not necessarily
only matz that is not the best fan of (mandatory?) typing additions to
ruby. I, for instance, always feel that the typing makes ruby uglier. This
is also subjective of course, and as long as I can defend my code base 
against mandatory typing I don't quite care as much anyway. People can
then use what they want - as long as I don't have to I have no real gripe
with it, even if I am not the biggest fan. But it's not correct to assume
only matz would not be the biggest fan - others may not be the biggest fans
either. You had a similar situation with the "it versus implicit numbering
of block arguments", by the way. People felt that "it" is more expressive
than implicit numbers and even if I may not be completely convinced that
this is the case, they do have a point too, at the least when one compares
"it" to _1 _2 _3. (Kokubun also made another good argument that _1 may 
imply more than one number too, which is not always true, and I agree with
that point of view.)

PS: In regards to "defp", others may wonder why pattern matching gets its
own keyword. Why not other functionality too? We could perhaps reason in
favour of "defa", "defb" and so forth and I am not sure it may all be 
necessary or make sense to have a proliferation of special-purpose keywords.

----------------------------------------
Feature #19764: Introduce defp keyword for defining overloadable, pattern matched methods
https://bugs.ruby-lang.org/issues/19764#change-103870

* Author: zeke (Zeke Gabrielse)
* Status: Open
* Priority: Normal
----------------------------------------
Pattern matching has become one of my favorite features of Ruby, if not my favorite. It changed the way I write and express my thoughts through clean, maintainable code. And I'd like to use it *more*.

I propose a new keyword, `defp`, for defining a method which applies pattern matching to its arguments.

```ruby
defp call(String => s unless s in /^[a-z]/)
  puts "string: #{s.inspect} (capitalized)"
end

defp call(String => s)
  puts "string: #{s.inspect}"
end

defp call(Hash(foo:, bar:) => h)
  puts "hash: #{h.inspect}"
end

defp call(**nil)
  puts "no keyword args"
end

call("Example") # => string: "Example" (capitalized)
call("test")    # => string: "test"
call(foo: 1, bar: 2) 
# => hash: { :foo => 1, :bar => 2 }
```

Internally, this could be represented as the following `case..in` pseudocode:

```ruby
def call(...)
  case ...
  in String => s unless s in /foo/
    puts "string: #{s.inspect} (not foo)"
  in String => s
    puts "string: #{s.inspect}"
  in Hash(foo:, bar:) => h
    puts "hash: #{h.inspect}"
  in **nil
    puts "no keyword args"
  else
    raise NoMatchingMethod
  end
end
```

As you could imagine, this could be used to refactor a lot of code, making the developer's intent much clearer. From [complex methods that use `case` statements](https://github.com/rails/rails/blob/593893c901f87b4ed205751f72df41519b4d2da3/actionpack/lib/action_dispatch/routing/url_for.rb#L173-L193) for taking varied arguments (I'm sure all our code bases contain such `case` statements), to defining smaller, simpler methods that handle particular argument patterns.

In addition, not only can this improve code quality, but it brings in method overloads, and it also adds a way to define more typing to the language -- something that RBS has tried to do, to mixed reactions -- but in a more Ruby-like way that Rubyists are already learning *and loving*.

Thoughts?

Original idea by Victor Shepelev: https://zverok.space/blog/2023-05-05-ruby-types.html

Further discussion: https://news.ycombinator.com/item?id=35834351



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- [email protected]
 To unsubscribe send an email to [email protected]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

Thread

Prev Next

In This Thread

Prev Next