[#41431] [ruby-trunk - Bug #5694][Open] Proc#arity doesn't take optional arguments into account. — Marc-Andre Lafortune <ruby-core@...>
Maybe we can add a new arity_range method that does this?
On Thu, Dec 1, 2011 at 6:54 PM, Yehuda Katz <wycats@gmail.com> wrote:
You could probably extract the information from #parameters, yeah.
On Thu, Dec 1, 2011 at 11:13 PM, Yehuda Katz <wycats@gmail.com> wrote:
Yeahit would be nice to be able to do:
[#41435] [ruby-trunk - Feature #5695][Open] CoffeeScript "is" and "isnt" keywords — Suraj Kurapati <sunaku@...>
[#41456] [ruby-trunk - Bug #5700][Open] fork {} segfaults during VM cleanup when run inside Fiber — Eric Wong <normalperson@...>
[#41478] [ruby-trunk - Feature #5707][Open] temporary file creation without finalizer and delegate. — Akira Tanaka <akr@...>
Akira Tanaka <akr@fsij.org> wrote:
2011/12/5 Eric Wong <normalperson@yhbt.net>:
[#41496] [ruby-trunk - Bug #5714][Open] Unexpected error of STDIN#read with non-ascii input on Windows XP — Heesob Park <phasis@...>
Hello,
Hello,
Hello,
[#41511] [ruby-trunk - Bug #5719][Open] Hash::[] can't handle 100000+ args — Nick Quaranto <nick@...>
[#41541] [ruby-trunk - Feature #5726][Open] Process::EXIT_SUCCESS and Process::EXIT_FAILURE — Akira Tanaka <akr@...>
[#41557] [ruby-trunk - Bug #5730][Open] Optinal block parameters assigns wrong — Yukihiro Matsumoto <matz@...>
2011/12/9 Yukihiro Matsumoto <matz@ruby-lang.org>:
Hi,
Hi Matz,
[#41581] [ruby-trunk - Bug #5737][Open] WEBrick doesn't support keep alive connections for 204 and 304 responses — Aaron Patterson <aaron@...>
[#41586] [ruby-trunk - Feature #5741][Open] Secure Erasure of Passwords — Martin Bosslet <Martin.Bosslet@...>
[#41592] My bug evaluation criteria — Marc-Andre Lafortune <ruby-core-mailing-list@...>
I don't think there is an official way to judge a bug, but for me it
[#41594] [ruby-trunk - Bug #5746][Open] Proc#curry too strict about lambda's arity. — Marc-Andre Lafortune <ruby-core@...>
[#41618] [ruby-trunk - Bug #5754][Open] Double require bug in 1.9.3 — Evan Phoenix <evan@...>
[#41630] redmine.ruby-lang.org -> bugs.ruby-lang.org — Shugo Maeda <shugo@...>
Hello,
[#41634] [ruby-trunk - Bug #5759][Open] flatten calls to_ary on everything — Thomas Sawyer <transfire@...>
[#41656] [ruby-trunk - Bug #5763][Open] sprintf not throwing error for wrong number of arguments — NagaChaitanya Vellanki <me@...>
[#41662] [ruby-trunk - Bug #5765][Open] [PATCH] modernize Timeout usage in net/{http,pop,smtp,telnet} — Eric Wong <normalperson@...>
[#41668] [ruby-trunk - Feature #5766][Open] Hash.each_with_object should behave differently when block's arity is 3 — Rodrigo Rosenfeld Rosas <rr.rosas@...>
[#41672] [ruby-trunk - Feature #5767][Open] Cache expanded_load_path to reduce startup time — Yura Sokolov <funny.falcon@...>
[#41681] Documentation of the language itself (syntax, meanings, etc) — Rodrigo Rosenfeld Rosas <rr.rosas@...>
Since Ruby is built on top of simple concepts, most of the documentation
Em 15-12-2011 19:23, Gary Wright escreveu:
On Dec 15, 2011, at 7:39 PM, Rodrigo Rosenfeld Rosas wrote:
Em 19-12-2011 19:38, Eric Hodel escreveu:
On Dec 19, 2011, at 3:04 PM, Rodrigo Rosenfeld Rosas wrote:
Em 19-12-2011 23:35, Eric Hodel escreveu:
[#41691] Ruby IRC Presence Problem — Eero Saynatkari <ruby-ml@...>
Hi,
[#41717] Feature : optional argument in File.join — Michel Demazure <michel@...>
In Windows, when using File.join, one often ends with a path containing
On Mon, Dec 19, 2011 at 6:09 AM, Michel Demazure <michel@demazure.com> wrote:
Luis Lavena wrote in post #1037331:
Hi,
On Tue, Dec 20, 2011 at 02:12, Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
Hi,
On Tue, Dec 20, 2011 at 08:17, Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
Nikolai Weibull wrote in post #1037488:
[#41721] Ruby and oniguruma relation. — V咜 Ondruch <v.ondruch@...>
Hi everybody,
[#41725] [ruby-trunk - Feature #5778][Open] Allow WEBrick::HTTPResponse to send IO-duck-typed bodies — Alex Young <alex@...>
[#41728] [ruby-trunk - Feature #5781][Open] Query attributes (attribute methods ending in `?` mark) — Thomas Sawyer <transfire@...>
[#41774] [ruby-trunk - Feature #5788][Open] Thread#at_exit — Masaki Matsushita <glass.saga@...>
[#41780] [Backport93 - Backport #5793][Open] Please backport r33662, r33666 — Jon Forums <redmine@...>
[#41787] Breaking while loading — Nikolai Weibull <now@...>
Hi!
[#41797] [ruby-trunk - Feature #5805][Open] object_hexid — Thomas Sawyer <transfire@...>
[#41799] Best way to separate implementation specific code? — Luis Lavena <luislavena@...>
Hello,
2011/12/24 Luis Lavena <luislavena@gmail.com>:
Hello,
On Sun, Dec 25, 2011 at 10:51 PM, U.Nakamura <usa@garbagecollect.jp> wrote:
Hello,
Hello,
Hi,
On Tue, Dec 27, 2011 at 11:21 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
Hi,
On Tue, Dec 27, 2011 at 11:44 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
[#41812] [ruby-trunk - Feature #5809][Open] Benchmark#bm: remove the label_width parameter — Benoit Daloze <redmine@...>
[#41841] YAML has become very slow under 1.9 — j.wuttke <j.wuttke@...>
The simple script
[#41848] [ruby-trunk - Feature #5826][Open] When the RUBY API_VERSION will be increased? — Ayumu AIZAWA <ayumu.aizawa@...>
[ruby-core:41772] Re: [ruby-trunk - Feature #5474][Assigned] keyword argument
Hi,
Not sure why the following modifications made in redmine were not
posted on the mailing list...
While having fun testing your patch, I encountered an issue with more
than 2 rest arguments:
def foo(*rest, b: 0, **options)
[rest, options]
end
foo(1, 2, bar: 0) # => [[1, 2], {bar: 0}] OK
foo(1, 2, 3, bar: 0) # => [[1, 2, {bar: 0}], {bar: 0}] Not OK
On 30 October 2011 11:10, Yusuke Endoh <mame@tsg.ne.jp> wrote:
> Currently, my patch allows ** only when there are one or more
> keyword arguments.
>
> This is because I didn't think of any use case.
> In addition, I wanted to simplify the implementation of parser.
> (Unfortunately, adding a new argument type requries *doubling*
> the parser rules to avoid yacc's conflict)
> Do you think we need it?
I'm worried about cases where one doesn't use named arguments directly
but wants to pass them on to another method.
Let's say we have a Gem that defines:
def import(*files, format: :auto_detect, encoding: "utf-8")
# ...
end
Say one wants to implement a variation of this that prints out a
progression. If it was possible to have a ** arg, one could:
def my_import(*files, **options)
puts "Importing #{files.size} files: #{files}"
import(*files, options)
end
A new version of the gem can modify the method `import` by adding
options, or changing the default of any option, add options and
`my_import` would work perfectly.
But if we can't define it this way, we have to do some artificial hoop
jumping. Either:
def my_import(*files, format: :auto_detect, encoding: "utf-8")
puts "Importing #{files.size} files: #{files}..."
import(*files, format: format, encoding: encoding)# ...
end
Downsides: verbose, won't pass on any new options, default changes
won't be reflected
def my_import(*files, format: :auto_detect, **options)
puts "Importing #{files.size} files: #{files}"
import(*files, options.merge(format: format))# ...
end
Downsides: verbose, format looks like a special option and if its
default changes in the Gem, it won't be reflected, but others will
def my_import(*args)
files = args.dup
files.pop if files.last.respond_to?(:to_hash)
puts "Importing #{files.size} files: #{files}"
import(*args)
end
Downside: `*args` less clear then `*files, **options`, slower, verbose, ...
I feel that the first (currently illegal) version is the much nicer
than the alternatives.
> I didn't implement caller's **.
> I wonder if we need it or not. Is "other(a, h)" not enough?
I think one reason to have it is to avoid calling Hash#merge when
combining options, like in the above examples.
Instead of
def foo(bar: 42, **options)
baz(extra_option: 1, **options)
end
Currently, one has to do:
def foo(bar: 42, **options)
baz(options.merge(extra_option: 1))
end
Benoit Daloze wrote:
> 2) I'm a bit dubious about the `**h` syntax to get (and I guess to pass) a Hash though.
> ...
> Something related to `{}`, the literal Hash syntax, would fit better in my opinion.
>
> Do you have any idea of an alternate syntax to `**h` ?
I haven't given much thought, but here's an alternate suggestion,
where **h => {*h}:
def foo(a, b=1, *rest, {c: 2, d: 3, *options})
end
If the parser allows, the {} could be optional, at least in the case
without a "hash-rest" argument.
This could actually be two new concepts that could be used everywhere
in Ruby (not just for argument passing):
a) Splat inside a hash does a merge, e.g.
h = {foo: 1, bar: 2}
{*h, baz: 3} # => {foo: 1, bar: 2, baz: 3}
I'm not sure if it should be silent in case of duplicate key (like
`Hash#merge` with no block) or if it should raise an error.
b) Hash destructuring, e.g.:
h = {foo: 1, bar: 2}
{foo: 42, extra: 0, *rest} = h
foo # => 1
extra # => 0
rest # => {bar: 2}
It would be nice to not need a default:
{foo, extra, *rest} = h
extra # => nil
This could be allowed in arguments too:
def foo(a, b=1, *rest, {c, d, *options})
end
What do you think?