[#84867] [Ruby trunk Bug#14357] thread_safe tests suite segfaults — v.ondruch@...

Issue #14357 has been reported by vo.x (Vit Ondruch).

11 messages 2018/01/15

[#84980] [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — hsbt@...

Issue #13618 has been updated by hsbt (Hiroshi SHIBATA).

10 messages 2018/01/23
[#85012] Re: [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — Eric Wong <normalperson@...> 2018/01/23

hsbt@ruby-lang.org wrote:

[ruby-core:85056] [Ruby trunk Feature#14392] Pipe operator

From: zverok.offline@...
Date: 2018-01-24 15:13:31 UTC
List: ruby-core #85056
Issue #14392 has been updated by zverok (Victor Shepelev).


Let me, then, introduce some philosphy here (I know this issue will be rejected anyways, so whatever).

When you propose new language feature, it is often useful to think a bit of it: how it plays with other features and general language intuition? Would it benefit from existing concepts, or will require the introduction of a bunch of new concepts? Will it look similar to other situations or strikingly dissimilar "special case just for the prettyness for one particular usage"?

```ruby
value |> method_name
```
...is really awful on all those accounts. 

What is `method_name` here? Because in ALL other contexts, naked `method_name` means immediate call of the method. Can we have proc there? If no, why? If yes, how it will be compatible with `method_name` syntax?

Applying some "next processing" to ONE value is strikingly different from applying some to COLLECTION:

In Elixir:

```elixir
collection |> Enumerable.map(...)
one_value |> String.split(...)
```
In Ruby 2.5

```ruby
collection.map { ... }
one_value.yield_self { ... }
# with some method
collection.map(&method(:puts))
one_value.yield_self(&method(:puts))
```

Your proposal:

```ruby
collection.map { ... }
one_value |> something
```

It already looks messed up :)

I agree that `yield_self(&method(:puts))` is less-than-optimal. Two problems here are:

* `method()`, the price we pay for having `()`-less method calls; there are ongoing discussions of shorthand syntax;
* REALLY unfortunate `yield_self` name, which I'll never get tired to blame.

But otherwise, it is perfectly idiomatic and readable Ruby, playing well with all usual metaphors and intuitions.

People tend to constantly mix "syntax akin to other language" or "syntax as I imagine it in my head" with "syntax which is clear and idiomatic". ¯\\\_(ツ)_/¯

----------------------------------------
Feature #14392: Pipe operator
https://bugs.ruby-lang.org/issues/14392#change-69774

* Author: dsferreira (Daniel Ferreira)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
I would like to see implemented in ruby a pipe operator as we have in elixir.

An example of application I have in mind is this:

```ruby
class Foo

  def bar(var)
    puts “Hello #{var}!”
  end |> private
  
  def baz(arg)
    bar(arg)
  end 
 
end

foo = Foo.new
foo.baz("Fred") # => "Hello Fred!"
```

It can also help simplify method chains:

```ruby
class Secret

  def initialise(user, password)
    @user = user
    @password = password
  end

  def second_pass(encrypted_string)
    encrypted_string.chain_4.chain_5.chain_6
  end |> private

  ##
  #  Super encryption

  def super_encryption
    @password.chain_1.chain_2.chain_3
      |> second_pass
  end |> public

end
```

And also simplify codes like this:

```ruby
class Foo

  def bar(*args)
    baz = args.select { |arg| arg =~ /regex/ }.first
    good?(baz)
  end

  public :bar

  def good(arg)
    arg.to_s.size > 10
  end
  
  private :good

end
```

to become:

```ruby
class Foo

  ##
  # Bar public method.

  def bar(*args)
    args.select { |arg| arg =~ /regex/ }.first
      |> good?
  end |> public

  def good(arg)
    arg.to_s.size > 10
  end |> private

end
```

Lots of local variables would be saved and I would expect some performance improvements with that.



-- 
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>

In This Thread

Prev Next