From: shevegen@...
Date: 2017-09-17T17:16:02+00:00
Subject: [ruby-core:82845] [Ruby trunk Bug#13913] Method definition with explicitly callable method names

Issue #13913 has been updated by shevegen (Robert A. Heiler).


> I cannot understand "But you may want to discuss the issue further." correctly.

I think it means that matz has not made up his mind completely yet, not so much
about the feature itself, but how to implement it.

I do not have a good proposal either. I think that both suggestions have advantages
and disadvantages. The suggestion with the '|' is simple, so that the information
is right there within the method "signature" - just an array. The disadvantage is
that the '|' is used, and I don't know if this is good or bad, but it is definitely
a change. (If the syntax is changed then I think it should be a target for ruby 3.x)

Matz' suggestion has the advantage of simpler syntax or at the least not a syntax
change (such as no '|') but one disadvantage may be that one has to look to the
module/interface specification yes? To find out what it may require and where that
information may be defined. This may be a very minor issue, but I only mention it
to compare it with the above proposal where the information would be part of the
method signature. (I am not sure if I like the '|' character but I think that this
is a secondary issue - one could, in principle, try to use something else ... or
even attach an additional signature to methods. But I guess that is all for
ruby-3.x ideas).

It is not easy to come up with a better syntax by the way; I tried to, but it is
difficult. Making changes to syntax used within arguments to methods is not trivial.

For example:

    def foobar(argument|a,b,c)
    def foobar(argument { respond_to: [:a,:b,:c] } )

I find my suggestion on the second line to be too verbose and too packed with sigil
stuff. :)

If it is for ruby 3.x then perhaps one could add a signature indication before a
method definition. Matz gave an example of conform(), I think similar alternatives 
could perhaps be used. Perhaps a generic way to decorate/modify arguments for a
method, a bit similar to how ruby uses some hook-definitions (included, extended,
prepended, inherited ...) in theory one could also have something similar to this
for methods.

I think that one problem with the '|' variant is ... how many arguments can you
pass into it? It would mean that you can pass in only one argument? Since
foobar('2','3','4') invocation would no longer work? Or would it be more like
*argument, and we would check whether the whole Array conforms to the interface
specification?

I think most will agree that the idea is useful, just how to find a way to make
it integrated is not trivial. To me the biggest difficulty is in finding a good
idiom syntax-wise to express the ruby hacker's wish to specify interface-behaviour
for arguments to some methods (I guess many other methods will not need it, so
this should also be kept in mind).

----------------------------------------
Bug #13913: Method definition with explicitly callable method names
https://bugs.ruby-lang.org/issues/13913#change-66736

* Author: tagomoris (Satoshi TAGOMORI)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: 
* Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
There are many cases to expect that arguments should respond to a/some methods like this:

```ruby
def call_foo(arg)
  if !(arg.respond_to(:to_s) and arg.respond_to(:to_a) and arg.respond_to(:readpartial))
    raise ArgumentError, "interface mismatch"
  end
end
```

This is very frequent pattern, and I'm very happy to write this code in very short lines like this:

```ruby
def call_foo(arg|to_s,to_a,readpartial)
  # ...
end
```

This feature looks very useful and have space to analyze statically and to optimize dynamically.
And, there may be possibility to allow to have method overriding.

What do you think about this idea?



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>