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:
-
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 
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 with public’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.
eigenclass.org
send!, then. 
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.
eigenclass.org
send!, then.
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: Avdi Grimm, Code Cleric
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?
-
makes testing easier / cleaner.
-
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-----