Use pattern to define private method by default

ruby-talk
1

Hi ruby community,

What are your thoughts regarding a pattern to define a private method by
default?

e.g.

class Bar
  def foo_
    "Foo"
  end
end

Bar.new().foo_

#=> NoMethodError: private method `foo_' called for

This would be very handy for my private methos organisation.

The pattern I envision would use a common character in the end of the
method name. It needs to be in the end.

2

Hi ruby community,

What are your thoughts regarding a pattern to define a private method by
default?

I am pretty sure this is not going to get accepted into Ruby core,
because there is not enough need for this and it obscures the
readability.

This would be very handy for my private methos organisation.

If you need lots of private methods, why not just use the "private" key
word alone rather than explicitely using it for each method?

    class Foo
      def pubmethod
        # ...
      end

      private

      def privmethod1
        # ...
      end

      def privmethod2
        # ...
      end

      def privmethod3
        # ...
      end
    end

All methods following the "private" keyword in the above example are
private.

Greetings
Marvin

···

On Fri, Jan 13, 2017 at 11:43:09AM +0000, Daniel Ferreira wrote:

--
Blog: http://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F

3

Hi ruby community,

What are your thoughts regarding a pattern to define a private method by
default?

e.g.

class Bar
  def foo_
    "Foo"
  end
end

Bar.new().foo_

#=> NoMethodError: private method `foo_' called for

This would be very handy for my private methos organisation.

The pattern I envision would use a common character in the end of the
method name. It needs to be in the end.

···

On 13 January 2017 at 21:43, Daniel Ferreira <subtileos@gmail.com> wrote:
~~~
class Bar
  private def foo
    "Foo"
  end
end
~~~
​

--
  Matthew Kerwin
  http://matthew.kerwin.net.au/

4

Because I don't like it.

I like to have my methods organised in alphabetical order in order to have
common logic gathered near by.
Also I like to look at a method and understand what is its visibility.
All of this is very important to save time when doing code reviews or
inspecting current code to develop new features.

My rules are very strict on this regard.

···

On Fri, 13 Jan 2017 at 12:01, Marvin Gülker <m-guelker@phoenixmail.de> wrote:

On Fri, Jan 13, 2017 at 11:43:09AM +0000, Daniel Ferreira wrote:

> Hi ruby community,

>

> What are your thoughts regarding a pattern to define a private method by

> default?

I am pretty sure this is not going to get accepted into Ruby core,

because there is not enough need for this and it obscures the

readability.

> This would be very handy for my private methos organisation.

If you need lots of private methods, why not just use the "private" key

word alone rather than explicitely using it for each method?

    class Foo

      def pubmethod

        # ...

      end

      private

      def privmethod1

        # ...

      end

      def privmethod2

        # ...

      end

      def privmethod3

        # ...

      end

    end

All methods following the "private" keyword in the above example are

private.

Greetings

Marvin

--

Blog: http://www.guelkerdev.de

PGP/GPG ID: F1D8799FBCC8BC4F

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

5

> What are your thoughts regarding a pattern to define a private method by
> default?

Rightly or wrongly, I don't memoise quite like this. I don't bother with the private method:

    def full_name
      @full_name ||= first_name + last_name
    end

I won't move the memoising calculation into a method unless it gets more complex than that. And if I do, I want to see it as a regular private method, not as some special thing. After all, it isn't -- it's the memoising that is the weird, special part, not the calculation.

My 10p.

Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer&gt;

6

> > What are your thoughts regarding a pattern to define a private method
by

> > default?

Rightly or wrongly, I don't memoise quite like this. I don't bother with
the private method:

    def full_name

      @full_name ||= first_name + last_name

    end

I won't move the memoising calculation into a method unless it gets more
complex than that. And if I do, I want to see it as a regular private
method, not as some special thing. After all, it isn't -- it's the
memoising that is the weird, special part, not the calculation.

My 10p.

Totally agree.

It was a simple illustration.

I only use it when I need two or more lines of code or de code is rather

complex even for a line like for instance the line extension.

So the question is for general cases where we do need memoisation.

···

On Fri, 13 Jan 2017 at 12:08, Andy Jones <Andy.Jones@jameshall.co.uk> wrote:

Click here to view Company Information and Confidentiality Notice.<
http://www.jameshall.co.uk/index.php/small-print/email-disclaimer&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

7

> > What are your thoughts regarding a pattern to define a private method
by

> > default?

Rightly or wrongly, I don't memoise quite like this. I don't bother with
the private method:

    def full_name

      @full_name ||= first_name + last_name

    end

I won't move the memoising calculation into a method unless it gets more
complex than that. And if I do, I want to see it as a regular private
method, not as some special thing. After all, it isn't -- it's the
memoising that is the weird, special part, not the calculation.

My 10p.

Totally agree.

It was a simple illustration.

I only use it when I need two or more lines of code or de code is rather
complex even for a line like for instance the line extension.

So the question is for general cases where we do need memoisation.

I have the feeling this should be on the other conversation!

Click here to view Company Information and Confidentiality Notice.<
http://www.jameshall.co.uk/index.php/small-print/email-disclaimer&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

···

On Fri, 13 Jan 2017 at 12:11, Daniel Ferreira <subtileos@gmail.com> wrote:

On Fri, 13 Jan 2017 at 12:08, Andy Jones <Andy.Jones@jameshall.co.uk> > wrote:

8

Hi ruby community,

What are your thoughts regarding a pattern to define a private method by
default?

e.g.

class Bar
  def foo_
    "Foo"
  end
end

Bar.new().foo_

#=> NoMethodError: private method `foo_' called for

This would be very handy for my private methos organisation.

The pattern I envision would use a common character in the end of the
method name. It needs to be in the end.

~~~
class Bar
  private def foo
    "Foo"
  end
end
~~~
​
Readability is affected with that.

What I do now is:

~~~
class Bar
  def foo
    "Foo"
  end

  private :foo
end
~~~

It's at I like the most out of all options I know of but doesn't make me
happy at all.

--
  Matthew Kerwin
  http://matthew.kerwin.net.au/

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

···

On Fri, 13 Jan 2017 at 12:14, Matthew Kerwin <matthew@kerwin.net.au> wrote:

On 13 January 2017 at 21:43, Daniel Ferreira <subtileos@gmail.com> wrote:

9

I have the feeling this should be on the other conversation!

My apologies -- I thought that the two posts were discussing the same question.

If you specifically want, in general, a way to set the default to be that methods are private? Well, I'm afraid my opinion on that is that we already have a way to do that and we don't need another.

The fact that it doesn't work for you and the aesthetic choices you have made is genuinely a shame. But language features have to consider all our, vastly varied, aesthetic choices, while keeping the syntax as simple as possible.

For example, if I were to sort my methods alphabetically I definitely wouldn't be putting common logic together. I put the public methods together because they form the contract that the class makes with the rest of the system. But, that's just my aesthetic choice.

Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer&gt;

10

>>>>>

I have the feeling this should be on the other conversation!

<<<<<

My apologies -- I thought that the two posts were discussing the same
question.

If you specifically want, in general, a way to set the default to be that
methods are private? Well, I'm afraid my opinion on that is that we
already have a way to do that and we don't need another.

The fact that it doesn't work for you and the aesthetic choices you have
made is genuinely a shame. But language features have to consider all our,
vastly varied, aesthetic choices, while keeping the syntax as simple as
possible.

For example, if I were to sort my methods alphabetically I definitely
wouldn't be putting common logic together. I put the public methods
together because they form the contract that the class makes with the rest
of the system. But, that's just my aesthetic choice.

How do you do when you look at a pr and you need to understand what is
what on it?

The API reference should be the documentation.

If you look at proper documented ruby code like Rails code base you will

see that your option of putting public methods all together makes no
difference for that purpose.

You are not able to look at most of public Rails classes and understand

from that view what is the contract.

Complex systems are not made by classes of 4 or 5 public methods without

···

On Fri, 13 Jan 2017 at 12:59, Andy Jones <Andy.Jones@jameshall.co.uk> wrote:

any documentation are they?

Click here to view Company Information and Confidentiality Notice.<
http://www.jameshall.co.uk/index.php/small-print/email-disclaimer&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

11

irb(main):003:0> class C; def foo;end; def bar_; end;
instance_methods(false).each {|m| /_$/ =~ m and private m}; end
=> [:foo, :bar_]
irb(main):004:0> C.private_instance_methods(false)
=> [:bar_]

You can use that

class Module
  def privatize
    instance_methods(false).each {|m| /_$/ =~ m and private m}
  end
end

class Foo
  def a_; end
  def b; end
  def c_; end

  privatize
end

p Foo.private_instance_methods(false)

robert

···

On Fri, Jan 13, 2017 at 1:05 PM, Daniel Ferreira <subtileos@gmail.com> wrote:

Because I don't like it.

I like to have my methods organised in alphabetical order in order to have
common logic gathered near by.
Also I like to look at a method and understand what is its visibility.
All of this is very important to save time when doing code reviews or
inspecting current code to develop new features.

My rules are very strict on this regard.

--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/

12

That comes inline with my thoughts.

Is it worthy making a gem of it and taking the discussion to ruby core?

···

On Fri, 13 Jan 2017 at 15:11, Robert Klemme <shortcutter@googlemail.com> wrote:

On Fri, Jan 13, 2017 at 1:05 PM, Daniel Ferreira <subtileos@gmail.com> > wrote:

> Because I don't like it.

>

> I like to have my methods organised in alphabetical order in order to
have

> common logic gathered near by.

> Also I like to look at a method and understand what is its visibility.

> All of this is very important to save time when doing code reviews or

> inspecting current code to develop new features.

>

> My rules are very strict on this regard.

irb(main):003:0> class C; def foo;end; def bar_; end;

instance_methods(false).each {|m| /_$/ =~ m and private m}; end

=> [:foo, :bar_]

irb(main):004:0> C.private_instance_methods(false)

=> [:bar_]

You can use that

class Module

  def privatize

    instance_methods(false).each {|m| /_$/ =~ m and private m}

  end

end

class Foo

  def a_; end

  def b; end

  def c_; end

  privatize

end

p Foo.private_instance_methods(false)

robert

--

[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can

- without end}

http://blog.rubybestpractices.com/

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Thanks Robert.

13

Would be perfect if we didn't have to do the call to `privatize`.

What about some solution with `Module#method_added` in mind?

Daniel

···

On Fri, 13 Jan 2017 at 15:20, Daniel Ferreira <subtileos@gmail.com> wrote:

On Fri, 13 Jan 2017 at 15:11, Robert Klemme <shortcutter@googlemail.com> > wrote:

On Fri, Jan 13, 2017 at 1:05 PM, Daniel Ferreira <subtileos@gmail.com> > wrote:

> Because I don't like it.

>

> I like to have my methods organised in alphabetical order in order to
have

> common logic gathered near by.

> Also I like to look at a method and understand what is its visibility.

> All of this is very important to save time when doing code reviews or

> inspecting current code to develop new features.

>

> My rules are very strict on this regard.

irb(main):003:0> class C; def foo;end; def bar_; end;

instance_methods(false).each {|m| /_$/ =~ m and private m}; end

=> [:foo, :bar_]

irb(main):004:0> C.private_instance_methods(false)

=> [:bar_]

You can use that

class Module

  def privatize

    instance_methods(false).each {|m| /_$/ =~ m and private m}

  end

end

class Foo

  def a_; end

  def b; end

  def c_; end

  privatize

end

p Foo.private_instance_methods(false)

robert

--

[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can

- without end}

http://blog.rubybestpractices.com/

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Thanks Robert.
That comes inline with my thoughts.

Is it worthy making a gem of it and taking the discussion to ruby core?

14

Hi Daniel,
could you use the indentation to keep your text from the replied-to text,
looks like you didn't add anything in all the previous mails, still I checked its also indented as the original text!

Thanks Opti!

···

On 2017-01-13 14:31, Daniel Ferreira wrote:

On Fri, 13 Jan 2017 at 12:59, Andy Jones <Andy.Jones@jameshall.co.uk > <mailto:Andy.Jones@jameshall.co.uk>> wrote:

    >>>>>

    I have the feeling this should be on the other conversation!

    <<<<<

    My apologies -- I thought that the two posts were discussing the
    same question.

15

How do you do when you look at a pr and you need to understand what is what on it?

Each project has its own stylistic quirks, and I would expect that an incoming PR would have to at least make a nod towards that -- in the same way that, if I was making my own PR, I would try to fit in with the style of the existing code. Bottom line, though: If I'm not writing code that others can understand, then I'm not programming well, and I would make the same test of any code in a pull request.

The API reference should be the documentation.
If you look at proper documented ruby code like Rails code base you will see that your option of putting public methods all together makes no difference for that purpose.

Well, we weren't talking about documentation, but that's an interesting point. Are you saying that the order of the methods in the class doesn't matter, because the rdoc/yard web pages ignore them? You might be right -- but we both still prefer to order methods in the class in a particular way, don't we?

You are not able to look at most of public Rails classes and understand from that view what is the contract.
Complex systems are not made by classes of 4 or 5 public methods without any documentation are they?

I think we will have to agree to disagree about that. I think that ideally a class should have a clearly defined public interface with only a few methods. There are usually a few classes that end up breaking this rule in any project -- but those are compromises, not ideals to point to.

Much Smarter people than me (Sandi Metz, for example) advocate this.

Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer&gt;

16

You can make a gem of course if you like to.
But please don't discuss it to be a core feature.

···

On Fri, Jan 13, 2017 at 6:20 PM, Daniel Ferreira <subtileos@gmail.com> wrote:

On Fri, 13 Jan 2017 at 15:11, Robert Klemme <shortcutter@googlemail.com> > wrote:

On Fri, Jan 13, 2017 at 1:05 PM, Daniel Ferreira <subtileos@gmail.com> >> wrote:

> Because I don't like it.

>

> I like to have my methods organised in alphabetical order in order to
have

> common logic gathered near by.

> Also I like to look at a method and understand what is its visibility.

> All of this is very important to save time when doing code reviews or

> inspecting current code to develop new features.

>

> My rules are very strict on this regard.

irb(main):003:0> class C; def foo;end; def bar_; end;

instance_methods(false).each {|m| /_$/ =~ m and private m}; end

=> [:foo, :bar_]

irb(main):004:0> C.private_instance_methods(false)

=> [:bar_]

You can use that

class Module

  def privatize

    instance_methods(false).each {|m| /_$/ =~ m and private m}

  end

end

class Foo

  def a_; end

  def b; end

  def c_; end

  privatize

end

p Foo.private_instance_methods(false)

robert

--

[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can

- without end}

http://blog.rubybestpractices.com/

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Thanks Robert.

That comes inline with my thoughts.

Is it worthy making a gem of it and taking the discussion to ruby core?

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

17

Thanks

···

On Fri, 13 Jan 2017 at 14:37, Die Optimisten <inform@die-optimisten.net> wrote:

On 2017-01-13 14:31, Daniel Ferreira > > wrote:

On Fri, 13 Jan 2017 at 12:59, Andy Jones <Andy.Jones@jameshall.co.uk> > > wrote:

>>>>>

I have the feeling this should be on the other conversation!

<<<<<

My apologies -- I thought that the two posts were discussing

the same question.

Hi Daniel,

could you use the indentation to keep your text from the replied-to

text,

looks like you didn't add anything in all the previous mails, still

I checked its also indented as the original text!

Thanks Opti!

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Yes. I'm having some problems with gmail client in order to do that.

18

could you use the indentation to keep your text from the replied-to text,

Those of us using Outlook don't have much control over this, either -- this whole thread is pretty hard to read at my end, I think because the indentation is coming to me as extra line breaks??

As you can see I have reverted to 1980's mailing list mode. Best I can do. Sorry.

Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer&gt;

19

Hi Aleksey,

···

On Fri, 13 Jan 2017 at 15:27, Aleksey Ivanov <ialexxei@gmail.com> wrote:

You can make a gem of course if you like to.
But please don't discuss it to be a core feature.

On Fri, Jan 13, 2017 at 6:20 PM, Daniel Ferreira <subtileos@gmail.com> > wrote:

On Fri, 13 Jan 2017 at 15:11, Robert Klemme <shortcutter@googlemail.com> > wrote:

On Fri, Jan 13, 2017 at 1:05 PM, Daniel Ferreira <subtileos@gmail.com> > wrote:

> Because I don't like it.

>

> I like to have my methods organised in alphabetical order in order to
have

> common logic gathered near by.

> Also I like to look at a method and understand what is its visibility.

> All of this is very important to save time when doing code reviews or

> inspecting current code to develop new features.

>

> My rules are very strict on this regard.

irb(main):003:0> class C; def foo;end; def bar_; end;

instance_methods(false).each {|m| /_$/ =~ m and private m}; end

=> [:foo, :bar_]

irb(main):004:0> C.private_instance_methods(false)

=> [:bar_]

You can use that

class Module

  def privatize

    instance_methods(false).each {|m| /_$/ =~ m and private m}

  end

end

class Foo

  def a_; end

  def b; end

  def c_; end

  privatize

end

p Foo.private_instance_methods(false)

robert

--

[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can

- without end}

http://blog.rubybestpractices.com/

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Thanks Robert.
That comes inline with my thoughts.

Is it worthy making a gem of it and taking the discussion to ruby core?

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Why not take it to ruby core?

Isn't ruby about giving multiple choices to the users?
If the pattern is not mandatory what is the problem for it to be part of
ruby core?

It would be much better to handle it in the parser.

Are you thinking in using this methods as public or protected methods?

Daniel

20

Hi Andy,

···

On Fri, 13 Jan 2017 at 15:43, Andy Jones <Andy.Jones@jameshall.co.uk> wrote:

>>>>

How do you do when you look at a pr and you need to understand what is
what on it?

<<<<

Each project has its own stylistic quirks, and I would expect that an
incoming PR would have to at least make a nod towards that -- in the same
way that, if I was making my own PR, I would try to fit in with the style
of the existing code. Bottom line, though: If I'm not writing code that
others can understand, then I'm not programming well, and I would make the
same test of any code in a pull request.

>>>>

The API reference should be the documentation.

If you look at proper documented ruby code like Rails code base you will
see that your option of putting public methods all together makes no
difference for that purpose.

<<<<

Well, we weren't talking about documentation, but that's an interesting
point. Are you saying that the order of the methods in the class doesn't
matter, because the rdoc/yard web pages ignore them? You might be right --
but we both still prefer to order methods in the class in a particular way,
don't we?

>>>>

You are not able to look at most of public Rails classes and understand
from that view what is the contract.

Complex systems are not made by classes of 4 or 5 public methods without
any documentation are they?

<<<<

I think we will have to agree to disagree about that. I think that
ideally a class should have a clearly defined public interface with only a
few methods. There are usually a few classes that end up breaking this
rule in any project -- but those are compromises, not ideals to point to.

Much Smarter people than me (Sandi Metz, for example) advocate this.

Click here to view Company Information and Confidentiality Notice.<
http://www.jameshall.co.uk/index.php/small-print/email-disclaimer&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Hi agree with you.

SOLID should be the rule and in my organisation we follow it as much as we
can.
But it doesn't take away from you these problems I'm bringing here for
discussion.

These are problems I've been facing for years.