Hi, I don't like the way of declaring publi and private methods since it's not
really clear. AFAIK there are you ways:
1)
class C
def public_1
end
def public_2
end
private:
def private_1
end
public:
def public_3
end
or:
2)
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.
Hi, I don't like the way of declaring publi and private methods since it's not
really clear. AFAIK there are you ways:
1)
class C
def public_1
end
def public_2
end
private:
def private_1
end
public:
def public_3
end
or:
2)
class C
def public_1
end
def public_2
end
def private_1
end
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, 7:49 pm, Iñaki Baz Castillo <i...@aliax.net> 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
···
On Apr 24, 2008, at 16:49 , Iñaki Baz Castillo wrote:
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.
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__.
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?
···
On Thu, Apr 24, 2008 at 9:24 PM, Ryan Davis <ryand-ruby@zenspider.com> 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.
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
···
On Fri, Apr 25, 2008 at 8:18 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
2) there IS no real private/protected. Just try to keep me out if I want in.
···
On Apr 25, 2008, at 07:38 , Avdi Grimm 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?
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 Gilcher
···
On Apr 25, 2008, at 2:03 PM, Arlen Cuss wrote:
Abstracting the API is a good point, but perhaps they should be disconnected
in a manner other than using private/protected methods...
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
--
Rails training from David A. Black and Ruby Power and Light:
INTRO TO RAILS June 9-12 Berlin
ADVANCING WITH RAILS June 16-19 Berlin
INTRO TO RAILS June 24-27 London (Skills Matter)
See http://www.rubypal.com for details and updates!
The Ruby Programming Language says so on page 274.
···
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.
