RE: Singleton public methods

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:[email protected]] 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 <[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]

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 <[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]





On Behalf Of Daniel Ferreira








Sent: 12 December 2016 9:34 am








To:

[email protected]<mailto:[email protected]>








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:[email protected]<mailto:[email protected]>?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:[email protected]<mailto:[email protected]>?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:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>