[#59462] [ruby-trunk - Bug #9342][Open] [PATCH] SizedQueue#clear does not notify waiting threads in Ruby 1.9.3 — "jsc (Justin Collins)" <redmine@...>

9 messages 2014/01/02

[#59466] [ruby-trunk - Bug #9343][Open] [PATCH] SizedQueue#max= wakes up waiters properly — "normalperson (Eric Wong)" <normalperson@...>

11 messages 2014/01/02

[#59498] [ruby-trunk - Bug #9352][Open] [BUG] rb_sys_fail_str(connect(2) for [fe80::1%lo0]:3000) - errno == 0 — "kain (Claudio Poli)" <claudio@...>

10 messages 2014/01/03

[#59516] [ruby-trunk - Bug #9356][Open] TCPSocket.new does not seem to handle INTR — "charliesome (Charlie Somerville)" <charliesome@...>

48 messages 2014/01/03

[#59538] [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — "shyouhei (Shyouhei Urabe)" <shyouhei@...>

33 messages 2014/01/03
[#59582] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — SASADA Koichi <ko1@...> 2014/01/06

Intersting challenge.

[#59541] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — Eric Wong <normalperson@...> 2014/01/04

Hi, I noticed a trivial typo in array.c, and it fails building struct.c

[#59583] [ruby-trunk - Bug #9367][Open] REXML::XmlDecl doesn't use user specified quotes — "bearmini (Takashi Oguma)" <bear.mini@...>

12 messages 2014/01/06

[#59642] [ruby-trunk - Bug #9384][Open] Segfault in ruby 2.1.0p0 — "cbliard (Christophe Bliard)" <christophe.bliard@...>

11 messages 2014/01/08

[#59791] About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...>

A while ago I created a proof-of-concept that I intended to use in my

16 messages 2014/01/15
[#59794] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/15

On 15 Jan 2014, at 11:58, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[#59808] Re: About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2014/01/16

Em 15-01-2014 19:42, Eric Hodel escreveu:

[#59810] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/16

On 16 Jan 2014, at 02:15, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[#59826] Re: About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2014/01/17

Em 16-01-2014 19:43, Eric Hodel escreveu:

[#59832] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/17

On 17 Jan 2014, at 04:22, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[ruby-core:59878] Re: [ruby-trunk - Feature #9428] Inline argument expressions and re-assignment

From: Matthew Kerwin <matthew@...>
Date: 2014-01-20 00:19:03 UTC
List: ruby-core #59878
I'm -1 for this.

1. aesthetically: it puts some of the function's code outside the
function's body, which makes it harder to follow a function's execution
when reading code, and it makes the signature unnecessarily messy.

2. syntactically: none of the proposals you've given make enough sense, at
least for me personally to understand what they mean:

  def foo( arg.to_i )
  def foo( arg.to_i as arg )

Is the left-most 'arg' a local variable, or referring to self#arg, or
something else..?

> Ruby could auto-assign the passed argument to the first variable
encountered in the expression.

According to my understanding of the parser, any heretofore unseen
"bareword" tokens are interpreted as function calls, so there is no "first
variable encountered."  It works for optional positional parameters because
they have an equals sign in (and 'bareword = expression' is universally
lvar creation/assignment, in Ruby).

3. debugability: the 'def' line is a single line, however there's no real
limit to the number of parameters you can include in that line.  If each of
those parameters can include arbitrary expressions, well, I'd hate to have
to debug a "NoMethodError: undefined method ... for nil:NilClass" on that
line.  And if the answer to that is to split the 'def' line over multiple
lines, then why not just put the expressions on those multiple lines anyway?

4. orthogonality: what about non-optional keyword arguments?

For what it's worth, I'm not entirely *for* allowing arbitrary expressions
in optional parameters either, but in that case I can't think of a better
representation.  But if I ever seen anything more than a #[] call in a
default value I consider it Bad Form

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

In This Thread

Prev Next