Issue #14392 has been updated by dsferreira (Daniel Ferreira).


shevegen (Robert A. Heiler) wrote: 

> No |> though.

Hi Robert, many thanks for the extensive comment.
The idea of using `"|>"` as the proposed pipe operator came  from my analysis of https://bugs.ruby-lang.org/issues/13581 issue coupled with long time syntax thoughts.
I proposed a syntax sugar for `13581` as `"|>"` or `"<|"`. You can read the logic there.
It makes sense in my head.
Resembles the way bash instructions work in multiple directions.
Ruby also has a lot of sh/bash logic in its core.
Using `"|"` coupled with `"<"` and `">"` seems to me an easy and intuitive way to overcome the syntax problem of having the three operators already with their own meanings in isolation.

> But I also very rarely use private in ruby in the first place

People don't really care about it but I do care a lot.
I like to work in top of a very well defined API.
The library API should be reduced to its minimum as much as possible.
And I want total freedom to do whatever inside the library.
So I use extensively `public`, `protected` and `private`.
I have some feature requests still open that I'm planning to implement in the near future and submit a patch.
One of them is https://bugs.ruby-lang.org/issues/9992 which is about the introduction of an `internal` access modifier which would define an `internal` interface just visible to the library namespace.

So you can see that this matters are very important to me and impact my daily work.
I love ruby but I'm not being able to express myself in the language like I would like to.
We don't live in an ideal world I know but I believe that my way of seeing the design of a library/gem or module/class brings a new insight into the ecosystem that may be good to consider by the community.

It is not easy to present the full picture of what I have in my mind so I'm starting to do it bit by bit.
With time people will understand better what is my vision and what am I proposing.

> That is also why I do not completely agree with the rubocop style guide

I'm with you 100% on this.
But you know, when you work in a big company and if you are the only one speaking in one direction you better end your talk.
Rubocop is now the default in the enterprise ruby.
Luckily I'm now in a position where my voice is heard.
But what I can't do is to tell about features that just exist in my head.
So here I am trying to make my dream a reality.

> I think elixir is cool but ruby is not elixir

This proposal it is not about Elixir.
I have never coded a single line in Elixir and I'm not planning to do it in the near future.

I mentioned Elixir just as a reference nothing else.
It seems people like language references when discussing this matters.
If that is not the case please say so and I will stop using those references.


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

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