Iâm completely with you on the idea of contracts. Technically, I suppose you are right that protected methods are exposed to other objects and therefore part of the contract.
But I confess Iâve never found a use for a method that can only be accessed by other objects of the same class. The idea seems fundamentally non-OOP to me; my objects should not care where their incoming messages came from, or what sort of object they are sending messages to.
I think Matz is on-record as saying that protected is something he would do very differently now â not that that really matters.
From: ruby-talk [mailto:ruby-talk-***@ruby-lang.org] On Behalf Of Daniel Ferreira
Sent: 12 December 2016 10:29 am
To: Ruby users
Subject: Re: Singleton public methods
Maybe there is a space for a new feature request then?
I tend to use protected a lot.
The definition of the public interface is very important in my point of view.
I try to keep it as simple as possible.
Documentation is another component that I believe is very important.
When I want a private method to be documented I make it protected to emphasise that its importance.
A private method can be discarded at any time.
A protected method implies a contract in my way of looking at things.
It is what I call the *internal interface*
On Mon, 12 Dec 2016 at 10:20, Andy Jones <***@jameshall.co.uk<mailto:***@jameshall.co.uk>> wrote:
I was just looking at that. Iâm not âstrugglingâ with anything (although the example clearly shows four very different types of method, with either two or
three of them being singleton, depending⊠room for confusion there in my opinion).
I think, perhaps and in general, most people shy away from using protected methods. Which is perhaps why your use case isnât well supported.
It also looks as if you want the singleton methods on a module which contains the class? As I was trying to say in my previous post, I donât think you are
going to get a single call that treats those as singleton methods on the class; as the example we are both looking at shows, Ruby doesnât categorise them as such.
From: ruby-talk [mailto:ruby-talk-***@ruby-lang.org<mailto:ruby-talk-***@ruby-lang.org>]
On Behalf Of Daniel Ferreira
Sent: 12 December 2016 10:03 am
To: Ruby users
Subject: Re: Singleton public methods
Andy,
http://ruby-doc.org/core-2.3.0/Object.html#method-i-singleton_methods returns public and protected methods.
I'm only interested in the public ones.
The definition of singleton method I believe can be inferred by looking at the behaviour of this particular method.
If you keep struggling with it please say so and I will try to explain you.
On Mon, 12 Dec 2016 at 09:49, Andy Jones <***@jameshall.co.uk<mailto:***@jameshall.co.uk>> wrote:
Maybe youâd better spell out exactly what you mean by âsingleton methodsâ.
Itâs not a term I tend to use because people use it in different ways, I think?
I suspect that from the Ruby documentation point of view, methods on module
included in a class arenât singleton. Methods on a module included in an *object*,
inside a âclass << selfâ block, are.
From:
ruby-talk [mailto:ruby-talk-***@ruby-lang.org<mailto:ruby-talk-***@ruby-lang.org>]
On Behalf Of Daniel Ferreira
Sent: 12 December 2016 9:34 am
To:
ruby-***@ruby-lang.org<mailto:ruby-***@ruby-lang.org>
Subject: Singleton public methods
I would like retrieve a full list of singleton public methos for a `Foo` module and `Foo::Bar` class.
The best thing I was able to come up with was this:
```
Foo.singleton_methods(false) & Foo.public_methods
Foo::Bar.singleton_methods(false) & Foo::Bar.public_methods
```
It feels to me that we should have a better way of doing it.
Any ideas?
Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>
Unsubscribe: <mailto:ruby-talk-***@ruby-lang.org<mailto:ruby-talk-***@ruby-lang.org>?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>
Unsubscribe: <mailto:ruby-talk-***@ruby-lang.org<mailto:ruby-talk-***@ruby-lang.org>?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>