Procedure vs method


#1

What advantage or difference has a procedure (Proc) over a method?


#2

Kless wrote:

What advantage or difference has a procedure (Proc) over a method?

Is this for homework or something?

Ruby has no procedures, only methods. All methods have a hidden ‘self’
variable linking them to an object.

Beyond this, you are going to have to ask a more specific question -
preferrably one not answered by any tutorial - so we can give the best
answer!


#3

Hi –

On Mon, 13 Oct 2008, Kless wrote:

What advantage or difference has a procedure (Proc) over a method?

A method is executed as a direct result of sending a message to an
object:

“hello”.upcase # the message is ‘upcase’, which resolves to a
# method name

A Proc object gets called by sending it a message:

pr = Proc.new { puts “I am a Proc!” }
pr.call # prints: I am a Proc!

Every method is defined inside a class or module, and executing the
method depends on having an object that will be able to find the
method. Procs, however, are handed around like other objects: a Proc
you create in one context can be called in another. Procs do not
belong to classes or modules.

There’s more, but those are some basic differences.

David


#4

Hi –

On Mon, 13 Oct 2008, Phlip wrote:

Kless wrote:

What advantage or difference has a procedure (Proc) over a method?

Is this for homework or something?

Ruby has no procedures, only methods. All methods have a hidden ‘self’
variable linking them to an object.

I think you missed the “(Proc)” in the question. The question is about
Proc objects (which I think it’s reasonable to refer to as procedures,
though typically people don’t) in comparison with methods.

David


#5

On 12 oct, 22:18, “Phlip” removed_email_address@domain.invalid wrote:

Is this for homework or something?
I wanted to know why or when is used Proc because it looks that is the
same that a method.


#6

Kless wrote:

I wanted to know why or when is used Proc because it looks that is the
same that a method.

Often you use Procs that have been created from a block. Using a method
instead of a proc in that case is not really an option.
Other times you use Procs that you want to eventually pass to a method
as
parameter. You could use methods there, but that would somewhat pollute
the
namespace by defining a new method that you’re never gonna call directly
anyway.

HTH,
Sebastian


#7

2008/10/12 David A. Black removed_email_address@domain.invalid:

On Mon, 13 Oct 2008, Phlip wrote:

Ruby has no procedures, only methods. All methods have a hidden ‘self’
variable linking them to an object.

I think you missed the “(Proc)” in the question. The question is about
Proc objects (which I think it’s reasonable to refer to as procedures,
though typically people don’t) in comparison with methods.

IMHO it makes sense to not refer to Procs as “procedures” because they
actually are closures. This is a significant difference.

Kind regards

robert


#8

On Mon, Oct 13, 2008 at 1:02 AM, Robert K.
removed_email_address@domain.invalid wrote:

IMHO it makes sense to not refer to Procs as “procedures” because they
actually are closures. This is a significant difference.

For the original poster, here’s a quick illustration:

$ cat test.rb
a = 42

def foo
puts a
end

bar = Proc.new { puts a }

puts “calling bar”
bar.call

puts “calling foo”
foo

$ ruby test.rb
calling bar
42
calling foo
test.rb:4:in foo': undefined local variable or methoda’ for
main:Object (NameError)
from test.rb:13


#9

Martin DeMello wrote:

IMHO it makes sense to not refer to Procs as “procedures” because they
actually are closures. This is a significant difference.

For the original poster, here’s a quick illustration:

For the Ruby authors, here’s an upgrade:

a = 42

bar = Proc.new { puts a }

You can store ‘bar’ & use it later, and it stores its link to ‘a’.

An important goal of encapsulation is to give everything the narrowest
scope
possible. Without closure, if we need ‘a’ to have a lifespan as long as
‘bar’, we have to make ‘a’ into a data member. That widens 'a’s scope.

With closures, ‘a’ has the narrowest scope possible over a long
lifespan.
That is a major win - and it’s why platforms without closures don’t know
what they are missing!


#10

Hi –

On Mon, 13 Oct 2008, Robert K. wrote:

IMHO it makes sense to not refer to Procs as “procedures” because they
actually are closures. This is a significant difference.

Doesn’t that vary by language though? I assume Proc/proc stands for
“procedure”, so it’s hard to rule that out as something to call them.

David


#11

2008/10/13 David A. Black removed_email_address@domain.invalid:

On Mon, 13 Oct 2008, Robert K. wrote:

IMHO it makes sense to not refer to Procs as “procedures” because they
actually are closures. This is a significant difference.

Doesn’t that vary by language though? I assume Proc/proc stands for
“procedure”, so it’s hard to rule that out as something to call them.

Well, probably you are right although I do not know a language where
procedures are closures. OTOH you can say “proc” != “procedure”.

Anyway, I just wanted to point out that a Proc is more than a simple
procedure that accepts parameters works on them and probably returns
something.

Kind regards

robert


#12

On Mon, 13 Oct 2008, Robert K. wrote:

Well, probably you are right although I do not know a language where
procedures are closures.

Aren’t they in Lisp? I don’t mean that the terms are interchangeable,
but are there procedures in Lisp that are not closures on the bindings
in effect when they’re created? (I think there are in Scheme.)

OTOH you can say “proc” != “procedure”.

What else would it mean though?

Anyway, I just wanted to point out that a Proc is more than a simple
procedure that accepts parameters works on them and probably returns
something.

That’s the “There’s more” part of my original post :slight_smile: Closures, and
also method objects, which I didn’t mention, were the two things I had
chiefly in mind.

David


#13

2008/10/13 Phlip removed_email_address@domain.invalid:

An important goal of encapsulation is to give everything the narrowest scope
possible. Without closure, if we need ‘a’ to have a lifespan as long as
‘bar’, we have to make ‘a’ into a data member. That widens 'a’s scope.

With closures, ‘a’ has the narrowest scope possible over a long lifespan.
That is a major win - and it’s why platforms without closures don’t know
what they are missing!

I agree that it’s a powerful means but I’m not as enthusiastic as you
are. After all in OO languages you can easily emulate a closure by
creating a class with appropriate methods and data members. Closures
can on the other hand make code harder to comprehend because the
interaction between the closure and the local variable is not obvious.

Cheers

robert