[#70977] [Ruby trunk - Feature #11473] Immutable String literal in Ruby 3 — arai@...
Issue #11473 has been updated by Shunichi Arai.
3 messages
2015/10/04
[#71062] [Ruby trunk - Bug #10892] Deadlock in autoload — eregontp@...
Issue #10892 has been updated by Benoit Daloze.
4 messages
2015/10/12
[#71090] Re: [Ruby trunk - Bug #10892] Deadlock in autoload
— Eric Wong <normalperson@...>
2015/10/14
eregontp@gmail.com wrote:
[#71127] [Ruby trunk - Feature #11607] [PATCH] fiddle: release GVL for ffi_call — normalperson@...
Issue #11607 has been updated by Eric Wong.
3 messages
2015/10/20
[#71164] [Ruby trunk - Feature #11614] [Open] [RFC] use id_table for constant tables — normalperson@...
Issue #11614 has been reported by Eric Wong.
3 messages
2015/10/22
[#71211] [Ruby trunk - Feature #11607] [PATCH] fiddle: release GVL for ffi_call — naruse@...
Issue #11607 has been updated by Yui NARUSE.
6 messages
2015/10/27
[#71212] Re: [Ruby trunk - Feature #11607] [PATCH] fiddle: release GVL for ffi_call
— Eric Wong <normalperson@...>
2015/10/27
Yes, user must check if the function is MT-safe. Probably fine
[#71246] Re: [Ruby trunk - Feature #11607] [PATCH] fiddle: release GVL for ffi_call
— Aaron Patterson <tenderlove@...>
2015/10/28
On Tue, Oct 27, 2015 at 08:54:07AM +0000, Eric Wong wrote:
[#71254] Re: [Ruby trunk - Feature #11607] [PATCH] fiddle: release GVL for ffi_call
— Eric Wong <normalperson@...>
2015/10/28
Aaron Patterson <tenderlove@ruby-lang.org> wrote:
[#71230] [Ruby trunk - Feature #11625] Unlock GVL for SHA1 calculations — tenderlove@...
Issue #11625 has been updated by Aaron Patterson.
5 messages
2015/10/27
[#71236] Re: [Ruby trunk - Feature #11625] Unlock GVL for SHA1 calculations
— Юрий Соколов <funny.falcon@...>
2015/10/28
What's about other hashsum algos? MD5, SHA2, etc
[#71242] Re: [Ruby trunk - Feature #11625] Unlock GVL for SHA1 calculations
— Eric Wong <normalperson@...>
2015/10/28
Юрий Соколов <funny.falcon@gmail.com> wrote:
[#71239] [Ruby trunk - Bug #11384] multi-threaded autoload sometimes fails — shugo@...
Issue #11384 has been updated by Shugo Maeda.
4 messages
2015/10/28
[ruby-core:71273] Re: [Ruby trunk - Feature #11537] Introduce "Safe navigation operator"
From:
Matthew Kerwin <matthew@...>
Date:
2015-10-29 21:00:41 UTC
List:
ruby-core #71273
a..b already means something in ruby
I'm happy with Matz's acceptance of .? especially in light of all the
discussions that lead up to it.
On 30/10/2015 5:33 AM, <alonecomp@gmail.com> wrote:
> Issue #11537 has been updated by Laurentiu Macovei.
>
>
> The same discussion happens to be on TypeScript and ES6 worlds.
> Using .. instead of ?. or .? because it's way more clear when you are
> using the ternary ? : operator on the same line.
>
> If it's not a conflict in Ruby syntax perhaps worths looking at
>
>
> https://esdiscuss.org/topic/existential-operator-null-propagation-operator#content-65
> https://github.com/Microsoft/TypeScript/issues/16#issuecomment-152275052
>
> Posting the markdown info from there:
>
> This would be amazing operator!! Especially for `ES6`/`ES7`/`TypeScript` -
> and why not `Ruby` ?
>
> ```js
> var error = a.b.c.d; //this would fail with error if a, b or c are null or
> undefined.
> var current = a && a.b && a.b.c && a.b.c.d; // the current messy way to
> handle this
> var currentBrackets = a && a['b'] && a['b']['c'] && a['b']['c']['d'];
> //the current messy way to handle this
> var typeScript = a?.b?.c?.d; // The typescript way of handling the above
> mess with no errors
> var typeScriptBrackets = a?['b']?['c']?['d']; //The typescript of handling
> the above mess with no errors
> ```
> However I propose a more clear one - as not to confuse ? from the a ? b :
> c statements with a?.b statements:
>
> ```js
> var doubleDots = a..b..c..d; //this would be ideal to understand that you
> assume that if any of a, b, c is null or undefined the result will be null
> or undefined.
> var doubleDotsWithBrackets = a..['b']..['c']..['d'];
> ```
>
> For the bracket notation, I recommend two dots instead of a single one as
> it's consistent with the others when non brackets are used. Hence only the
> property name is static or dynamic via brackets.
>
> Two dots, means if its null or undefined stop processing further and
> assume the result of expression is null or undefined. (as d would be null
> or undefined).
>
> Two dots make it more clear, more visible and more space-wise so you
> understand what's going on.
>
> This is not messing with numbers too - as is not the same case e.g.
>
> ```js
> 1..toString(); // works returning '1'
> var x = {};
> x.1 = {y: 'test' }; //fails currently
> x[1] = {y: 'test' }; //works currently
> var current = x[1].y; //works
> var missing= x[2].y; //throws exception
> var assume= x && x[2] && x[2].y; // works but very messy
> ```
>
> About numbers two options: Your call which one can be adopted, but I
> recommend first one for compatibility with existing rules!
> 1. Should fail as it does now (`x.1.y` == `runtime error`)
> ```js
> var err = x..1..y; // should fail as well, since 1 is not a good property
> name, nor a number to call a method, since it's after x object.
> ```
> 2. Should work since it understands that is not a number calling a
> property from `Number.prototype`
> ```js
> var err = x..1..y; // should work as well, resulting 'test' in this case
> var err = x..2..y; // should work as well, resulting undefined in this case
> ```
>
>
> With dynamic names:
> ```js
> var correct1 = x..[1]..y; //would work returning 'test'
> var correct2 = x..[2]..y; //would work returning undefined;
> ```
>
> What do you think folks?
>
> P.S. `foo?.bar` and `foo?['bar']` syntax would work too.
>
> However the using both current `?` `:` operator and `?.` might be very
> confusing on the same line.
>
> e.g. using `?.` and `?['prop']`
> ```js
> var a = { x: { y: 1 } };
> var b = condition ? a?.x.?y : a?.y?.z;
> var c = condition ? a?['x']?['y'] : a?['y']?['z'];
> ```
> as opposed to double dots `..` and `..['prop']`
> ```js
> var a = { x: { y: 1 } };
> var b = condition ? a..x..y : a..y..z;
> var c = condition ? a..['x']..['y'] : a..['y']..['z'];
> ```
>
> ##### Which one does look more clear to you?
>
> ----------------------------------------
> Feature #11537: Introduce "Safe navigation operator"
> https://bugs.ruby-lang.org/issues/11537#change-54644
>
> * Author: Hiroshi SHIBATA
> * Status: Closed
> * Priority: Normal
> * Assignee: Yukihiro Matsumoto
> ----------------------------------------
> I sometimes write following code with rails application:
>
> ```ruby
> u = User.find(id)
> if u && u.profile && u.profile.thumbnails && u.profiles.thumbnails.large
> ...
> ```
>
> or
>
> ```ruby
> # Use ActiveSupport
> if u.try!(:profile).try!(:thumbnails).try!(:large)
> ...
> ```
> I hope to write shortly above code. Groovy has above operator named "Safe
> navigation operator" with "`?.`" syntax.
> Ruby can't use "`?.`" operator.
>
> Can we use "`.?`" syntax. like this:
>
> ```ruby
> u = User.find(id)
> u.?profile.?thumbnails.?large
> ```
>
> Matz. How do you think about this?
>
>
>
>
> --
> https://bugs.ruby-lang.org/
>