* [ruby-core:96508] [Ruby master Feature#16456] Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters
[not found] <redmine.issue-16456.20191227004215@ruby-lang.org>
@ 2019-12-27 0:42 ` aaronc20000
2019-12-27 11:29 ` [ruby-core:96511] " eregontp
` (4 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: aaronc20000 @ 2019-12-27 0:42 UTC (permalink / raw)
To: ruby-core
Issue #16456 has been reported by aaronc81 (Aaron Christiansen).
----------------------------------------
Feature #16456: Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters
https://bugs.ruby-lang.org/issues/16456
* Author: aaronc81 (Aaron Christiansen)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
A method defined with `...` as its parameter list is equivalent to one defined with `*args, &blk`, according to `Method#parameters`.
```
def foo(...); end
p method(:foo).parameters
# => [[:rest, :*], [:block, :&]]
```
Even in Ruby 2.7, `...` and `*args, &blk` are not _quite_ equivalent as the latter may produce a warning where the former does not. In Ruby 3.0 and beyond, `...` and `*args, &blk` will have a substantial semantic difference. Due to this, I don't consider the current behaviour of `Method#parameters` particularly ideal when dealing with methods using this new syntax.
If the goal of `...` is to be a "delegate everything" operator, even when parameter passing is changed like in Ruby 3.0, I would propose that `Method#parameters` considers it a unique type of parameter. For example:
```
def foo(...); end
p method(:foo).parameters
# => [[:delegate, :"..."]]
```
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ruby-core:96511] [Ruby master Feature#16456] Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters
[not found] <redmine.issue-16456.20191227004215@ruby-lang.org>
2019-12-27 0:42 ` [ruby-core:96508] [Ruby master Feature#16456] Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters aaronc20000
@ 2019-12-27 11:29 ` eregontp
2019-12-27 11:37 ` [ruby-core:96513] " zverok.offline
` (3 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: eregontp @ 2019-12-27 11:29 UTC (permalink / raw)
To: ruby-core
Issue #16456 has been updated by Eregon (Benoit Daloze).
I think it should be:
```ruby
[[:rest, :*], [:keyrest, :**], [:block, :&]]
```
because that's what it will act like in Ruby 3.0+.
Is there an advantage to have its own type of parameter?
That would make usages of `#parameters` more complex for I think very little gain.
----------------------------------------
Feature #16456: Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters
https://bugs.ruby-lang.org/issues/16456#change-83444
* Author: aaronc81 (Aaron Christiansen)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
A method defined with `...` as its parameter list is equivalent to one defined with `*args, &blk`, according to `Method#parameters`.
```ruby
def foo(...); end
p method(:foo).parameters
# => [[:rest, :*], [:block, :&]]
```
Even in Ruby 2.7, `...` and `*args, &blk` are not *quite* equivalent as the latter may produce a warning where the former does not. In Ruby 3.0 and beyond, `...` and `*args, &blk` will have a substantial semantic difference. Due to this, I don't consider the current behaviour of `Method#parameters` particularly ideal when dealing with methods using this new syntax.
If the goal of `...` is to be a "delegate everything" operator, even when parameter passing is changed like in Ruby 3.0, I would propose that `Method#parameters` considers it a unique type of parameter. For example:
```ruby
def foo(...); end
p method(:foo).parameters
# => [[:delegate, :"..."]]
```
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ruby-core:96513] [Ruby master Feature#16456] Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters
[not found] <redmine.issue-16456.20191227004215@ruby-lang.org>
2019-12-27 0:42 ` [ruby-core:96508] [Ruby master Feature#16456] Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters aaronc20000
2019-12-27 11:29 ` [ruby-core:96511] " eregontp
@ 2019-12-27 11:37 ` zverok.offline
2019-12-27 17:35 ` [ruby-core:96517] " aaronc20000
` (2 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: zverok.offline @ 2019-12-27 11:37 UTC (permalink / raw)
To: ruby-core
Issue #16456 has been updated by zverok (Victor Shepelev).
> I think it should be:
```ruby
[[:rest, :*], [:keyrest, :**], [:block, :&]]
```
(I have a deja vu we already discussed it :)))
Names are redundant, it should be just
```ruby
[[:rest], [:keyrest], [:block]]
```
Like this:
```ruby
def foo(*, **, &b)
end
p method(:foo).parameters
# => [[:rest], [:keyrest], [:block, :b]]
```
(Not sure about "block" parameter -- unnamed block parameters aren't existing in current Ruby)
----------------------------------------
Feature #16456: Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters
https://bugs.ruby-lang.org/issues/16456#change-83445
* Author: aaronc81 (Aaron Christiansen)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
A method defined with `...` as its parameter list is equivalent to one defined with `*args, &blk`, according to `Method#parameters`.
```ruby
def foo(...); end
p method(:foo).parameters
# => [[:rest, :*], [:block, :&]]
```
Even in Ruby 2.7, `...` and `*args, &blk` are not *quite* equivalent as the latter may produce a warning where the former does not. In Ruby 3.0 and beyond, `...` and `*args, &blk` will have a substantial semantic difference. Due to this, I don't consider the current behaviour of `Method#parameters` particularly ideal when dealing with methods using this new syntax.
If the goal of `...` is to be a "delegate everything" operator, even when parameter passing is changed like in Ruby 3.0, I would propose that `Method#parameters` considers it a unique type of parameter. For example:
```ruby
def foo(...); end
p method(:foo).parameters
# => [[:delegate, :"..."]]
```
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ruby-core:96517] [Ruby master Feature#16456] Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters
[not found] <redmine.issue-16456.20191227004215@ruby-lang.org>
` (2 preceding siblings ...)
2019-12-27 11:37 ` [ruby-core:96513] " zverok.offline
@ 2019-12-27 17:35 ` aaronc20000
2019-12-29 22:54 ` [ruby-core:96585] " daniel
2019-12-31 17:30 ` [ruby-core:96608] " aaronc20000
5 siblings, 0 replies; 6+ messages in thread
From: aaronc20000 @ 2019-12-27 17:35 UTC (permalink / raw)
To: ruby-core
Issue #16456 has been updated by aaronc81 (Aaron Christiansen).
> Is there an advantage to have its own type of parameter?
I believe the advantages of doing this are:
- If Ruby ever introduces a new type of parameter, the result of `#parameters` won't need to change for existing code which uses `...`, making upgrades easier. This is especially important if `...` is designed as a future-proof way of delegation, as then it seems important that its behaviour shouldn't change between versions.
- It could be useful for introspection to be able to differentiate between the two. For example, this could allow a complex DSL to assign a special meaning to `...`.
----------------------------------------
Feature #16456: Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters
https://bugs.ruby-lang.org/issues/16456#change-83449
* Author: aaronc81 (Aaron Christiansen)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
A method defined with `...` as its parameter list is equivalent to one defined with `*args, &blk`, according to `Method#parameters`.
```ruby
def foo(...); end
p method(:foo).parameters
# => [[:rest, :*], [:block, :&]]
```
Even in Ruby 2.7, `...` and `*args, &blk` are not *quite* equivalent as the latter may produce a warning where the former does not. In Ruby 3.0 and beyond, `...` and `*args, &blk` will have a substantial semantic difference. Due to this, I don't consider the current behaviour of `Method#parameters` particularly ideal when dealing with methods using this new syntax.
If the goal of `...` is to be a "delegate everything" operator, even when parameter passing is changed like in Ruby 3.0, I would propose that `Method#parameters` considers it a unique type of parameter. For example:
```ruby
def foo(...); end
p method(:foo).parameters
# => [[:delegate, :"..."]]
```
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ruby-core:96585] [Ruby master Feature#16456] Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters
[not found] <redmine.issue-16456.20191227004215@ruby-lang.org>
` (3 preceding siblings ...)
2019-12-27 17:35 ` [ruby-core:96517] " aaronc20000
@ 2019-12-29 22:54 ` daniel
2019-12-31 17:30 ` [ruby-core:96608] " aaronc20000
5 siblings, 0 replies; 6+ messages in thread
From: daniel @ 2019-12-29 22:54 UTC (permalink / raw)
To: ruby-core
Issue #16456 has been updated by Dan0042 (Daniel DeLorme).
In the future it will be possible to combine `...` with other arguments. So if we think about what `parameters` would return in cases like these...
```ruby
method(def foo(a, *args, ...); end).parameters
#1=> [[:req, :a], [:rest, :args], [:delegate]]
#2=> [[:req, :a], [:rest, :args], [:keyrest], [:block]]
#3=> [[:req, :a], [:rest, :args], [:rest], [:keyrest], [:block]]
method(def foo(a, **kw, ...); end).parameters
#1=> [[:req, :a], [:keyrest, :kw], [:delegate]]
#2=> [[:req, :a], [:keyrest, :kw], [:rest], [:block]]
#3=> [[:req, :a], [:keyrest, :kw], [:rest], [:keyrest], [:block]]
```
I see the point of wanting to know if the method signature includes `...` or not, but I don't think I like the idea of having a `:delegate` that can mean different things.
What about this?
`[[:rest, :"..."], [:keyrest, :"..."], [:block, :"..."]]`
----------------------------------------
Feature #16456: Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters
https://bugs.ruby-lang.org/issues/16456#change-83552
* Author: aaronc81 (Aaron Christiansen)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
A method defined with `...` as its parameter list is equivalent to one defined with `*args, &blk`, according to `Method#parameters`.
```ruby
def foo(...); end
p method(:foo).parameters
# => [[:rest, :*], [:block, :&]]
```
Even in Ruby 2.7, `...` and `*args, &blk` are not *quite* equivalent as the latter may produce a warning where the former does not. In Ruby 3.0 and beyond, `...` and `*args, &blk` will have a substantial semantic difference. Due to this, I don't consider the current behaviour of `Method#parameters` particularly ideal when dealing with methods using this new syntax.
If the goal of `...` is to be a "delegate everything" operator, even when parameter passing is changed like in Ruby 3.0, I would propose that `Method#parameters` considers it a unique type of parameter. For example:
```ruby
def foo(...); end
p method(:foo).parameters
# => [[:delegate, :"..."]]
```
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ruby-core:96608] [Ruby master Feature#16456] Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters
[not found] <redmine.issue-16456.20191227004215@ruby-lang.org>
` (4 preceding siblings ...)
2019-12-29 22:54 ` [ruby-core:96585] " daniel
@ 2019-12-31 17:30 ` aaronc20000
5 siblings, 0 replies; 6+ messages in thread
From: aaronc20000 @ 2019-12-31 17:30 UTC (permalink / raw)
To: ruby-core
Issue #16456 has been updated by aaronc81 (Aaron Christiansen).
I think that the `[[:rest, :"..."], [:keyrest, :"..."], [:block, :"..."]]` solution looks like a good option, as it keeps roughly the same behaviour while adding the differentiation between `*args, &blk` and `...`.
----------------------------------------
Feature #16456: Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters
https://bugs.ruby-lang.org/issues/16456#change-83578
* Author: aaronc81 (Aaron Christiansen)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
A method defined with `...` as its parameter list is equivalent to one defined with `*args, &blk`, according to `Method#parameters`.
```ruby
def foo(...); end
p method(:foo).parameters
# => [[:rest, :*], [:block, :&]]
```
Even in Ruby 2.7, `...` and `*args, &blk` are not *quite* equivalent as the latter may produce a warning where the former does not. In Ruby 3.0 and beyond, `...` and `*args, &blk` will have a substantial semantic difference. Due to this, I don't consider the current behaviour of `Method#parameters` particularly ideal when dealing with methods using this new syntax.
If the goal of `...` is to be a "delegate everything" operator, even when parameter passing is changed like in Ruby 3.0, I would propose that `Method#parameters` considers it a unique type of parameter. For example:
```ruby
def foo(...); end
p method(:foo).parameters
# => [[:delegate, :"..."]]
```
--
https://bugs.ruby-lang.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-12-31 17:30 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <redmine.issue-16456.20191227004215@ruby-lang.org>
2019-12-27 0:42 ` [ruby-core:96508] [Ruby master Feature#16456] Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters aaronc20000
2019-12-27 11:29 ` [ruby-core:96511] " eregontp
2019-12-27 11:37 ` [ruby-core:96513] " zverok.offline
2019-12-27 17:35 ` [ruby-core:96517] " aaronc20000
2019-12-29 22:54 ` [ruby-core:96585] " daniel
2019-12-31 17:30 ` [ruby-core:96608] " aaronc20000
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).