Forum: Ruby Procedure vs method

125aa997aecefa6ebd4431f9b89e0bed?d=identicon&s=25 Kless (Guest)
on 2008-10-12 22:25
(Received via mailing list)
What advantage or difference has a procedure (Proc) over a method?
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2008-10-12 23:21
(Received via mailing list)
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!
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2008-10-12 23:27
(Received via mailing list)
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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2008-10-12 23:31
(Received via mailing list)
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
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2008-10-13 10:05
(Received via mailing list)
2008/10/12 David A. Black <dblack@rubypal.com>:
> 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
125aa997aecefa6ebd4431f9b89e0bed?d=identicon&s=25 Kless (Guest)
on 2008-10-13 10:41
(Received via mailing list)
On 12 oct, 22:18, "Phlip" <phlip2...@gmail.com> 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.
7a561ec0875fcbbe3066ea8fe288ec77?d=identicon&s=25 Sebastian Hungerecker (Guest)
on 2008-10-13 11:06
(Received via mailing list)
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
Ae16cb4f6d78e485b04ce1e821592ae5?d=identicon&s=25 Martin DeMello (Guest)
on 2008-10-13 11:38
(Received via mailing list)
On Mon, Oct 13, 2008 at 1:02 AM, Robert Klemme
<shortcutter@googlemail.com> 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 method `a' for
main:Object (NameError)
  from test.rb:13
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2008-10-13 12:27
(Received via mailing list)
Hi --

On Mon, 13 Oct 2008, Robert Klemme 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
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2008-10-13 12:45
(Received via mailing list)
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!
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2008-10-13 13:32
(Received via mailing list)
2008/10/13 Phlip <phlip2005@gmail.com>:

> 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
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2008-10-13 13:35
(Received via mailing list)
2008/10/13 David A. Black <dblack@rubypal.com>:

> On Mon, 13 Oct 2008, Robert Klemme 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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2008-10-13 13:50
(Received via mailing list)
On Mon, 13 Oct 2008, Robert Klemme 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 :-) Closures, and
also method objects, which I didn't mention, were the two things I had
chiefly in mind.


David
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.