[#75687] [Ruby trunk Bug#12416] struct rb_id_table lacks mark function — shyouhei@...
Issue #12416 has been reported by Shyouhei Urabe.
3 messages
2016/05/23
[#75763] [Ruby trunk Feature#12435] Using connect_nonblock to open TCP connections in Net::HTTP#connect — mohamed.m.m.hafez@...
Issue #12435 has been reported by Mohamed Hafez.
3 messages
2016/05/28
[#75774] Errno::EAGAIN thrown by OpenSSL::SSL::SSLSocket#connect_nonblock — Mohamed Hafez <mohamed.m.m.hafez@...>
Hi all, every now and then in my production server, I'm
4 messages
2016/05/30
[#75775] Re: Errno::EAGAIN thrown by OpenSSL::SSL::SSLSocket#connect_nonblock
— Mohamed Hafez <mohamed.m.m.hafez@...>
2016/05/30
Or does MRI's OpenSSL::SSL::SSLSocket#connect_nonblock just return
[#75782] Important: Somewhat backwards-incompatible change (Fwd: [ruby-cvs:62388] duerst:r55225 (trunk): * string.c: Activate full Unicode case mapping for UTF-8) — Martin J. Dürst <duerst@...>
With the change below, I have activated full Unicode case mapping for
4 messages
2016/05/31
[ruby-core:75676] [Ruby trunk Bug#12412] Extend safe navigation operator
From:
danieldasilvaferreira@...
Date:
2016-05-22 10:28:29 UTC
List:
ruby-core #75676
Issue #12412 has been updated by Daniel Ferreira.
Another improvement to make it even more powerful.
Introduction of a new global variable that would return the object which didn't respond to the method breaking the safe navigation chain.
Although we need to think about concurrency as well and performance.
Just an idea:
~~~ ruby
foo = ''
def foo.bar
1
end
foo&.bar&.baz
# => nil
$NEW_GLOBAL_VARIABLE_OR_SOMETHING_ELSE
# => 1
~~~
----------------------------------------
Bug #12412: Extend safe navigation operator
https://bugs.ruby-lang.org/issues/12412#change-58808
* Author: Daniel Ferreira
* Status: Open
* Priority: Normal
* Assignee:
* ruby -v:
* Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
I wonder if we couldn't extend the safe navigation operator to work with any object rather than just nil.
I tend to still use this kind of code in some scenarios, specially when I work with objects with dynamic interfaces or arguments with different possible object types:
~~~ ruby
class Foo
def bar(baz)
if baz.respond_to?(:qux)
return baz.qux
end
'whatever'
end
end
~~~
What if we extend the safe navigation operator to work with any kind of object?
If it doesn't respond to the method it would return nil like this:
~~~ ruby
class Foo
def bar(baz)
baz&.qux || 'whatever'
end
end
~~~
In order to not break backwards compatibility we should keep the current behaviour as well so the rational would be:
~~~ ruby
nil&.any_method
# => nil
foo&.non_responding_method
# => nil
~~~
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>