[ruby-core:95342] [Ruby master Feature#16253] Shorthand "forward everything" syntax

[shevegen@gmail.com]

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


Hmm. I have not decided whether I like the proposal or not; I guess I am mostly
neutral, but with a slight tendency towards not being in favour of it. But leaving
this aside, I think there are perhaps a few points of note.

1) Part of this proposal reminds me of delegate/delegation, e. g. delegating calls
from one object to another - a bit like the Forwardable module may do. So a small
issuer may be for other ruby users to understand the difference(s), towards the
proposal here, and the forwardable module.

2) I think the core idea behind the proposal is primarily to save some keys, which
on the one hand may be nice; on the other hand .... hmmm. To me personally, I do
not understand why * would or could be used/retrofitted into meaning to "just
pass all arguments". You also wrote that you are fine with other syntax; I 
believe that it may be better to see whether we could come up with another
syntax altogether that still is short, could be used here, without adding a new
meaning to *.

Benoit mentioned that there were other tickets for use of (...); I am not sure
if there are other tickets for this specifically, but I recall having read that
in other tickets, perhaps even proposed by matz (I don't remember, sorry).

I think using (...) would be a bit better than using/retrofitting *, even
though * uses fewer characters. I am not a huge fan of (...) either though,
but I do not dispute that it can be, in principle, useful. (Actually I just
noticed that the link Benoit used pointed to your own suggestion. :D)

Personally I think getting the syntax "right" would be best. I am not sure
how useful it would be, or how often it could be used; that might also have
to be kept in mind. The recent python 3.8.0 release, for example, there
was quite some discussion here and there about how useful or often used
some of these features are. IMO whenever possible, the more people who CAN
use a feature, and who also WILL use a feature, the better - so getting the
syntax "right" here would be important.

I don't have a good proposal myself though.

I'll use a verbose dummy-example:

    def foo(*bar)
      @some_other_object.foo(yield_arguments)

That's way too verbose, but I guess it may illustrate the goal of 
wanting to "yield the arguments onto that method". Actually we may
have that already? Or perhaps not ... we have __method__ ... perhaps
we may need __arguments__ too and then some syntactic sugar for 
it. It also reminds me a bit of "yield" and &proc - but anyway, 
IMO syntax matters. .foo(...) is a bit better than .foo(*) IMO,
but not perfect. It may be difficult to get "great" results with 
very short syntax alone, withouting losing meaning.

> And we'd even be future-proof if an eventual FOURTH kind of
> parameter is introduced!!!!

I don't think this is a good argument ;) because IF this were a
problem, one could always suggest a proposal to see a change.

You can even find old joke-proposals such as:

    def foo
      def bar
        def ble
    enddd

Or something like that. :P (Although I do have to admit that using several "end"
can be a bit tedious; I just think that was a joke proposal since ... who in his
sane mind wants to just spam the character "d", to mean end-of-scope, as several
"end" would mean. Mandatory indent is also not that great either; I hate that I
can't just copy/paste into the interactive python interpreter. IRB's behaviour is
so much nicer and more convenient here.)

> If rubyists must be told they have to change their forwarding code in 2.7
> (due to keyword arguments), the pill might be easier to swallow if the change
> is a reduction rather than an increase in verbosity.

Well. I think matz said that this may be the only (or perhaps just one of the
very few) changes between 2.x and 3.0, possibly the biggest one. I don't know
the status about frozen Strings, but there are always those who like changes,
and those who don't. Giving people time to prepare to switch is, IMO, always
a good thing; it helps reduce problems in the long run. I don't think people
are THAT opposed to change. But to come back to your comment - I don't think
that the changes in regards to keyword arguments, should be connected to any
syntax proposal in regards to delegation, for several reason. One is that I
think they are not really that much connected; but also because the change in
regards to keywords came, at the least partially, because it was confusing
to many people. Matz even made jokes about it during some presentations.

I personally use oldschool hash options usually, barely any keyword arguments,
so I am not affected really either way. Perhaps it would also be interesting
to see what Jeremy thinks about syntax shortcuts/proposal in this regard,
not solely confined to (*) or (...) but just in general.


----------------------------------------
Feature #16253: Shorthand "forward everything" syntax
https://bugs.ruby-lang.org/issues/16253#change-82052

* Author: Dan0042 (Daniel DeLorme)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
What about using this:

```ruby
  def foo(*)
    @bar.foo(*)
```

to mean this:

```ruby
  def foo(*a, **o, &b)
    @bar.foo(*a, **o, &b)
```

I used `def foo(*)` because that's currently valid ruby code, but I'm fine with any syntax.

It's like the no-parentheses `super` shorthand, but for any method.

It makes it easier to write correct forwarding code. 

If rubyists must be told they have to change their forwarding code in 2.7 (due to keyword arguments), the pill might be easier to swallow if the change is a reduction rather than an increase in verbosity.

And we'd even be future-proof if an eventual FOURTH kind of parameter is introduced!!!!




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