General

Profile

rits (First Last)

  • Login: rits
  • Registered on: 11/04/2012
  • Last sign in: 10/29/2014

Issues

open closed Total
Assigned issues 0 0 0
Reported issues 2 15 17

Activity

09/25/2014

04:52 PM Ruby Bug #10142: named params don't always capture passed named args
another example of how this creates surprise, confusion and subtle bugs
~~~ruby
def foo(a = 1, **options)
end
foo opt: 2
~~~
_____________
if 'a' becomes mandatory, instead of raising, "a" will absorb the options, which is c...
rits (First Last)
01:44 AM Ruby Bug #10293: splatting an empty hash in a method invocation sends an argument to the method (should send nothing)
https://bugs.ruby-lang.org/issues/9291 is somewhat related
foo(**nil) should not raise since foo(*nil) does not and it's the more useful behavior
rits (First Last)

09/24/2014

11:57 PM Ruby Bug #10293 (Closed): splatting an empty hash in a method invocation sends an argument to the method (should send nothing)
irb(main):001:0> def foo; end; foo **{}
ArgumentError: wrong number of arguments (1 for 0)
note that splatting an empty array results in no arguments
this behavior is particularly problematic with send (dispatching to different me...
rits (First Last)

09/14/2014

04:43 AM Ruby Feature #10177: Hash#has_key? and Hash#has_value? should be deprecated
Tsuyoshi Sawada wrote:
> I don't understand how `has_key?` is better
I already explained it, all I can do is restate it.
When the predicate consists of a just single noun or adjective, there is only enough information in it to ask...
rits (First Last)

09/07/2014

08:33 PM Ruby Feature #10177: Hash#has_key? and Hash#has_value? should be deprecated
in the interest of maximizing the English readability and sensibility (self documentability) of predicates, it is key? that should be deprecated.
when you have an instance method predicate in the form receiver.noun? this reads in Engl...
rits (First Last)

08/22/2014

04:00 PM Ruby Bug #10142: named params don't always capture passed named args
First Last wrote:
> Koichi Sasada wrote:
> ...
Can you at least explain why this would not be better?
rits (First Last)

08/17/2014

04:36 AM Ruby Bug #10142: named params don't always capture passed named args
Koichi Sasada wrote:
> Sorry I missed this line.
> ...
having never studied the actual implementation, this is as concrete as I can make it
"before keyword args are packaged into a hash which is bound to a mandatory param, actual fi...
rits (First Last)
03:57 AM Ruby Bug #10142: named params don't always capture passed named args
Koichi Sasada wrote:
> (2014/08/16 12:49), meanlogin@gmail.com wrote:
> ...
I already stated what I think would make more sense:
before keyword args are packaged into a hash which is bound to a mandatory param, actual first class ke...
rits (First Last)

08/16/2014

03:49 AM Ruby Bug #10142: named params don't always capture passed named args
First Last wrote:
> Nobuyoshi Nakada wrote:
> ...
this example is particularly illustrative, it's absurd to complain about missing keyword b when the method is being passed keyword b
rits (First Last)
03:45 AM Ruby Bug #10142: named params don't always capture passed named args
Nobuyoshi Nakada wrote:
> Mandatory arguments have priority over keywords arguments.
instead of just restating what is, why don't you say why it should be this way.
before keyword args existed as first class citizens, it made sens...
rits (First Last)

Also available in: Atom