Is there any nomenclature for private methods?

Hi, I don’t like the way of declaring publi and private methods since
it’s not
really clear. AFAIK there are you ways:

class C
def public_1
end

def public_2
end

private:
def private_1
end

public:
def public_3
end

or:

class C
def public_1
end

def public_2
end

def private_1
end

def public_3

private :private_1
end

I prefer 2) but until the end of class it’s not easy to know if a method
is
public or private/protected. So i’m thinking about use a special
nomenclature
for private methods, for example:

def _private_1

Is there any “standar” for this? I’ve seen lost of ethods called
xxxx
or “_xxxxx” but not sure the reason of that name.

Thanks a lot.

On Apr 24, 7:49 pm, Iñaki Baz C. [email protected] wrote:

  1.  def public_3
    
     private :private_1
    

end

One way is do it immediately after the method. E.g.

     def private_1
     end
     private :private_1

     def public_3
     end

I’ve seen other coders use the declarations before every single method
regardless

     public
     def public_2
     end

     private
     def private_1
     end

     public
     def public_3
     end

I agree that these declarations are one of the “sore-eyes” of Ruby,
but what else can be done? Matz has always seemed against allowing:

private def foo()
end

In many ways it’s really not important though. A more Ruby-esque way
in my opinion is to just make them all public and document them
appropriately. There is the exception of method_missing’s behavior
however.

I prefer 2) but until the end of class it’s not easy to know if a method is
public or private/protected. So i’m thinking about use a special nomenclature
for private methods, for example:

    def _private_1

Is there any “standar” for this? I’ve seen lost of ethods called “xxxx
or “_xxxxx” but not sure the reason of that name.

An initial underscore or double underscore basically indicates
“special/avoid overwrite” --meaning it’s meant to reduce the
likelihood that someone else might define a method/attribute of the
same name. The most common occurrence is send.

T.

On Apr 24, 2008, at 16:49 , Iñaki Baz C. wrote:

xxxx
or “_xxxxx” but not sure the reason of that name.

I don’t ever use private or protected, but I do use that naming
convention to convey the notion. Don’t use double-underscore, that’s
basically considered reserved.

def _think_twice_before_calling

end

2008/4/25, Trans [email protected]:

I agree that these declarations are one of the “sore-eyes” of Ruby,
but what else can be done? Matz has always seemed against allowing:

private def foo()
end

Thanks, surely I’ll use:

def _private_method_1

end
private : _provate_mehtod_1

In many ways it’s really not important though. A more Ruby-esque way
in my opinion is to just make them all public and document them
appropriately.

But if you do a framework other people to programme in it maybe is
neccesary to abstract the API and use private methods as security,
isn’t?

An initial underscore or double underscore basically indicates
“special/avoid overwrite” --meaning it’s meant to reduce the
likelihood that someone else might define a method/attribute of the
same name. The most common occurrence is send.

Ok understood :wink:

Hi,

On Fri, Apr 25, 2008 at 8:18 PM, Iñaki Baz C. [email protected]
wrote:

But if you do a framework other people to programme in it maybe is
neccesary to abstract the API and use private methods as security,
isn’t?

But they’ve got your code anyway. They can see it and modify it if they
choose (for example… replacing all private's withpublic’s… then
what?).
Also, note you can always use `send’ to get around protection:

class Something
private
def hi
puts “Oops!”
end
end
=> nil

s = Something.new
=> #Something:0xb7a09274

s.hi
NoMethodError: private method `hi’ called for #Something:0xb7a09274
from (irb):10

s.send :hi
Oops!
=> nil

Abstracting the API is a good point, but perhaps they should be
disconnected
in a manner other than using private/protected methods…

Cheers,
Arlen

2008/4/25, Arlen C. [email protected]:

Also, note you can always use `send’ to get around protection:

I’ve read somewhere that Ruby 1.9 doesn’t allow it.

Hi,

On Fri, Apr 25, 2008 at 10:45 PM, Iñaki Baz C. [email protected]
wrote:

2008/4/25, Arlen C. [email protected]:

Also, note you can always use `send’ to get around protection:

I’ve read somewhere that Ruby 1.9 doesn’t allow it.

http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l24

send!, then. :slight_smile:

There’s an absolute monster of a thread about how this was named (from
'05)
starting here:

http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-talk/153672?153666-154682+split-mode-vertical

Arlen

Hi –

On Fri, 25 Apr 2008, Arlen C. wrote:

Hi,

On Fri, Apr 25, 2008 at 10:45 PM, Iñaki Baz C. [email protected]
wrote:

2008/4/25, Arlen C. [email protected]:

Also, note you can always use `send’ to get around protection:

I’ve read somewhere that Ruby 1.9 doesn’t allow it.

http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l24

send!, then. :slight_smile:

Unfortunately (in my opinion), I believe that’s been reverted, so that
#send will be what it always has been and a new method, #public_send,
will be send that only works on public methods.

David

On Apr 25, 2008, at 16:09 , David A. Black wrote:

Unfortunately (in my opinion), I believe that’s been reverted, so that
#send will be what it always has been and a new method, #public_send,
will be send that only works on public methods.

The Ruby P.ming Language says so on page 274.

On Thu, Apr 24, 2008 at 9:24 PM, Ryan D. [email protected]
wrote:

I don’t ever use private or protected, but I do use that naming convention
to convey the notion. Don’t use double-underscore, that’s basically
considered reserved.

def _think_twice_before_calling

end

Good lord, one of the [smaller] reasons I enjoy coding Ruby over
Python is avoiding that kind of ugliness. May I ask why you would
prefer that over real private/protected?


Avdi

Home: http://avdi.org
Developer Blog: http://avdi.org/devblog/
Twitter: http://twitter.com/avdi
Journal: http://avdi.livejournal.com

On Apr 25, 2008, at 07:38 , Avdi G. wrote:

Good lord, one of the [smaller] reasons I enjoy coding Ruby over
Python is avoiding that kind of ugliness. May I ask why you would
prefer that over real private/protected?

  1. makes testing easier / cleaner.

  2. there IS no real private/protected. Just try to keep me out if I
    want in.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 25, 2008, at 2:03 PM, Arlen C. wrote:

Abstracting the API is a good point, but perhaps they should be
disconnected
in a manner other than using private/protected methods…

Cheers,
Arlen

Actually, I see private and protected as hint of intension. Even in
Java, you can circumvent them.

The method is private => it’s for internal use - so don’t cry if it
gets changed in some minor version, you should not rely on it anyway.
So if you really, really have to use send, know the consequences.

Regards,
Florian G.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgR4rsACgkQJA/zY0IIRZYwpgCbB0QxAxv1sT7d4KP/gbWKqyvL
IFIAn2zmRT2OWz9cY/7PWJokRsUu4lbh
=1jKc
-----END PGP SIGNATURE-----

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs