General question (different between methods and functions)?

Hello everyone,

I have been discussing the difference between methods and functions with
a
friend, but we couldn’t agree on what method and function is?

I would be very glad if people can join us.
At the moment we have 2 definition for the names.

  1. first, both names are the same, you can use whatever you want, they
    refer
    to the same thing.

  2. functions is used outside class, so you can call them direct, they
    are
    global functions, whereas methods are inside classes, and you cannot
    call
    them direct without creating object of that class which have the
    methods.

What do you agree on, or what do you have in mind, when you hear
function or
method?

and Thanks :slight_smile:

Methods are associated with a receiver object.

Functions are not.

The only things you can call functions in Ruby are lambdas, blocks,
… Even then it’s not clear whether they are methods or functions.

Everything else is methods.

AFAIK.

Aur

On Mar 28, 2007, at 3:42 AM, SonOfLilit wrote:

Methods are associated with a receiver object.

Functions are not.

The only things you can call functions in Ruby are lambdas, blocks,
… Even then it’s not clear whether they are methods or functions.

Everything else is methods.

The above is all true, but we do sometimes refer to calling methods
in a “function-style” in Ruby. That’s when you call a method without
an explicit receiver. For example:

puts “Hello world!” # function-style
file.puts “Hello world!” # normal method call

Everything is still a method, this is just a name we use for the call
style.

I only bring it up because it is sometimes referred to in the
documentation for things like private scope and module_function.

James Edward G. II

Yamal Khaled Soueidan wrote:

to the same thing.

  1. functions is used outside class, so you can call them direct, they are
    global functions, whereas methods are inside classes, and you cannot call
    them direct without creating object of that class which have the methods.

What do you agree on, or what do you have in mind, when you hear
function or
method?

I think of them like this:

  • A method is a message to which an object responds.
  • A function is a mapping from a set of input arguments to an output
    value (possibly with side-effects).

By this definition, it is possible for an (object,message) pair to be
viewed as a function. In a sense, your point 1 above is closest to the
truth in Ruby - it’s not possible to define a function that’s not
implemented as a method on an object.

Thats what I meant, functions is used without the object, and are called
direct, whereas the methods is used with the object.

puts “this is a function”

File.puts “this is object.method”

Is this how everyone see it or do many people have different opinion on
this
subject?

Jamal S. wrote:

Thats what I meant, functions is used without the object, and are called
direct, whereas the methods is used with the object.

puts “this is a function”

File.puts “this is object.method”

Is this how everyone see it or do many people have different opinion on
this
subject?

…no! wait a second… isn’t a standalone function really an object?

On Mar 28, 2007, at 7:51 AM, Dave R. wrote:

opinion on
this
subject?

…no! wait a second… isn’t a standalone function really an object?

Yes, in Ruby it’s always messages being passed to objects. This is
just a name we use for the call style. It’s still a method call.

James Edward G. II

The answer does depend on the language in question!
The difference is small and (arguably) unimportant in Ruby. In C++ or
Objective-C the difference and distinction is more clear and more
important.

Some people would argue the semantic difference between a function
and a method, but in most cases, in most languages they’re pretty
much the same.
The main difference is that a method is “part” of an object. It must
understand (respond to) or “have” the method in its definition. (or
inherit the method from an ancestor class)

A function in the strictest sense is a bit of code that is defined
and named and can be called and run by that name. It may take
arguments (parameters) and / or return a value of some sort.

In Ruby almost everything is an object…

Objective-C, has a similar concept of methods and messages to Ruby,
but also has C as it’s strict subset, it is a good place to find out
about the differences and similarities.

Well, in Ruby everything is a object, so we don’t have any functions?
In VB you can have functions inside modules, so you can call them by
their
name…
PHP have many functions available on their site, which you use in your
projects www.php.net without using any class
C# doesn’t have any functions, because you cannot call any functions
direct,
but you can only make methods static and call them, but you still need
to to
use class.method.

The answer does depend on the language in question!

In general it must be like you described.

Functions:
A function in the strictest sense is a bit of code that is defined
and named and can be called and run by that name.

Methods:
The main difference is that a method is “part” of an object.

This must be the best definition. :smiley:

Alex Y. wrote:

I think of them like this:

  • A method is a message to which an object responds.
    [snip]
    By this definition, it is possible for an (object,message) pair to be
    viewed as a function.

Of course, the very existence of CLOS makes this definition a little
vague. Since then, it would be the tuple of a “message” and all the
objects (values really) it’s “sent to” (which, in CLOS, it quite isn’t,
since IIRC, the multiple-dispatch mechanism doesn’t have to use the most
specific class of either argument if it wouldn’t lead to a match), and
things go all manners of pear-shaped, making a method really only a
tuple of a message name and its arguments, where I can’t really see the
distinction between that and a function name and its arguments. (Based
on your definition only.)

David V.

Yamal Khaled Soueidan wrote:

Hello everyone,

I have been discussing the difference between methods and functions with a
friend, but we couldn’t agree on what method and function is?

Potayto, potahto.

Both are names for an abstraction over some bit of code that has Stuff
Going In and Stuff Going Out. For methods, commonly, what bit of code
gets executed depends on one of the things going in - some form of
polymorphic dispatch depending on an argument (this, in Ruby, being the
implicit self), and most commonly, on the type of this argument.

Of course, in Ruby, the type of self is -really- a Class object holding
a hash of methods. So the polymorphic dispatch depends on what’s
actually some special value in the type system. Doing away with the
“special” role of self.class, we might as well say that if you put
lambdas (which seem function -ish enough) in a hash and then call one
depending on some value (a key in this hash), you’re making a method
call (HI MR. GRAHAM!).

Going ad absurdum, if we accept that a “method” is anytime when
semantics of a message send / function call / etc. depends on the value
of an argument (or more (yay CLOS, the inexhaustible source of obscure
views on OO (and nested parens))), you could as well argue that OCaml
pattern matching is a form of polymorphic dispatch, making OCaml
functions methods. (Good luck trying to persuade those guys about that
without getting weird looks and getting asked “And this is important
why?”)

My $0.02 say that the distinction made more sense in C++, and keeping
both lingos was implementation details leaking into language syntax
leaking into programmer mindset, or in another language where a
polymorphic dispatch was a more ostentatious affair (Smalltalkesque “we
do it everywhere!”), and where noone bothered to think just how common
and trivial what’s happening under the hood (a table lookup of one sort
of another) is.

David V.
End Rant

David V. wrote:

objects (values really) it’s “sent to” (which, in CLOS, it quite isn’t,
since IIRC, the multiple-dispatch mechanism doesn’t have to use the most
specific class of either argument if it wouldn’t lead to a match), and
things go all manners of pear-shaped, making a method really only a
tuple of a message name and its arguments, where I can’t really see the
distinction between that and a function name and its arguments. (Based
on your definition only.)

Absolutely agreed. “Method” and “function” needn’t be (and as you’ve
shown, aren’t) exclusive terms.

On 3/29/07, Alex Y. [email protected] wrote:

vague. Since then, it would be the tuple of a “message” and all the

I have always thought of method as a function that takes an implicit
argument: the object self.

I imagine that the thing that made people invent OO was the basic
problem that often comes in procedural programming: I got this bunch
of data and this bunch of functions designed to operate on that. I
have to pass the data to every function every time I call it. Even it
I put it into a single structure I still have to pass the structure
around. Why cannot I just use some syntax that binds the function to
the data?

Of course, once the implicit argument is present one can also
implicitly include a dispatch table that defines what the function
actually does on the particular object. And talk in terms of abstract
views that no longer make the method look like a function. But it is
still a mental or syntax shortcut I guess.

But yes, shortcuts that clarify things that were hard to understand
before are immensely useful.

Thanks

Michal

John J. [email protected] wrote/schrieb
[email protected]:

A function in the strictest sense is a bit of code that is defined
and named and can be called and run by that name. It may take
arguments (parameters) and / or return a value of some sort.

A function does not need to be named, e.g.:
lambda { |x| 5 * x } [3]
I’d call this calling/running an anonymous function.

Regards
Thomas

On 3/28/07, David V. [email protected] wrote:

Going In and Stuff Going Out. For methods, commonly, what bit of code
call (HI MR. GRAHAM!).
something like this? :
Parked at Loopia