<p>In Lua, a function is no different from a method, except that a method has <code>this</code> as the first parameter, and calling a method on an object automatically passes the object as the first parameter. In C++, there is <a href="https://stackoverflow.com/a/1486279/16217248">special handling</a> of functions versus member functions.</p>
<p>The advantage of the first option is simplicity and flexibility, as there is no <em>'unnecessary'</em> distinction between methods and functions. But are there any disadvantages?</p>

<functions><methods>
What are the disadvantages of making methods just functions with a 'this' first parameter?
CC BY-SA 4.0
2023-07-05T18:08:25.820Z
What even is the alternate option? In every language methods are just functions
mousetail 'he-him'
CC BY-SA 4.0
2023-07-05T18:08:30.653Z
In Swift, there is a calling convention difference: methods always put `self` in a dedicated register, so the first argument (besides `self`) is in the same place either way. Not sure whether that's worth writing an answer for.
Bbrk24
CC BY-SA 4.0
2023-07-05T18:09:27.827Z
@mousetail It reads to me like they're asking about Java `void foo()` + `static void bar()` vs Python `def foo(self)` + `def bar()`.
Bbrk24
CC BY-SA 4.0
2023-07-05T18:24:05.817Z
In python you need `@staticmethod` for static methods
mousetail 'he-him'
CC BY-SA 4.0
2023-07-05T18:31:11.810Z
Lua doesn't actually have instance methods unless you count syntactic sugar - functions that take `this` as a first parameter still require a different syntax `a:b()` instead of `a.b()`
RubenVerg
CC BY-SA 4.0
2023-07-05T18:41:26.313Z
@RubenVerg `a:b(...)` is just syntactic sugar for `a.b(a, ...)`
CPlus
CC BY-SA 4.0
2023-07-05T19:39:46.500Z
Do you mean for transpiling object-oriented code to a non-OO language (so that `MyClass::MyFunction(int x, int y)` becomes something like `MyClass_MyFunction(MyClass* this, int x, int y)`)?  Or treating these as equivalent *within* one language?
dan04
CC BY-SA 4.0
2023-07-05T20:26:19.203Z
@user16217248-OnStrike I thought it was for (metaclass of a)`.b(a, ...)`, but anyways my point still stands, methods aren't "like functions but with a `this` parameter" they're functions with some sugar
RubenVerg
<p>In languages like Java, there are no &quot;free standing&quot; functions. Every function is a method, hence there is no reason to specify explicitly that you are calling a method.</p>
<p>If there are both methods and &quot;free standing&quot; functions like C++ or Python, <code>this.call()</code> looks like a useful way to show that the method is being called. However developer that defines and then calls mostly methods, not functions, may anyway prefer to mark explicitly that this is a free-standing function rather than the method call. This can be done by explicitly specifying the namespace: <code>my_functions::my_function(x)</code>.</p>

CC BY-SA 4.0
2023-07-06T12:30:03.780Z
2023-07-06T12:30:03.780Z
Audrius Meškauskas
<p>Maybe one advantage of having function/method be fundamentally different is, at the syntax level, making it easy to prove that your code doesn't perform method calls.</p>
<p>When reading C++ code, visually one can instantly tell if a call is going to be to a function or to a method:</p>
<pre><code>f(a, b);
a.g(b);
</code></pre>
<p>This might be useful to C++ programmers, as they sometimes want to know when a call could go through a <a href="https://en.wikipedia.org/wiki/Virtual_method_table" rel="nofollow noreferrer">vtable</a>, because of the potential cost of pointer indirection.</p>
<hr />
<p>I imagine that the reason it's like this is, back when C++ was made, OOP was still controversial and not well understood, things like <a href="https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax" rel="nofollow noreferrer">UCS</a> or <a href="https://en.wikipedia.org/wiki/Extension_method" rel="nofollow noreferrer">extension methods</a> hadn't been invented, and people just didn't want to confuse this brand new &quot;method&quot; concept (and its weird virtual/override magic) with a regular function.</p>
<p>Today, it just seems like a good idea to have a way to abstract over whether something is a method call or a function call, because they are so similar.</p>
<p>Maybe I'm completely wrong though.</p>

CC BY-SA 4.0
2023-07-05T20:43:19.580Z
2023-07-05T20:43:19.580Z
Eldritch Conundrum
# What are the disadvantages of making methods just functions with a 'this' first parameter?
Posted by: username_0 on 2023-07-05
In Lua, a function is no different from a method, except that a method has `this` as the first parameter, and calling a method on an object automatically passes the object as the first parameter. In C++, there is [special handling](https://stackoverflow.com/a/1486279/16217248) of functions versus member functions.

The advantage of the first option is simplicity and flexibility, as there is no *'unnecessary'* distinction between methods and functions. But are there any disadvantages?
**Tags:** functions methods
> **Comments:**
> **username_1**: What even is the alternate option? In every language methods are just functions  
> **username_2**: In Swift, there is a calling convention difference: methods always put `self` in a dedicated register, so the first argument (besides `self`) is in the same place either way. Not sure whether that's worth writing an answer for.  
> **username_2**: @mousetail It reads to me like they're asking about Java `void foo()` + `static void bar()` vs Python `def foo(self)` + `def bar()`.  
> **username_1**: In python you need `@staticmethod` for static methods  
> **username_3**: Lua doesn't actually have instance methods unless you count syntactic sugar - functions that take `this` as a first parameter still require a different syntax `a:b()` instead of `a.b()`  
> **username_0**: @RubenVerg `a:b(...)` is just syntactic sugar for `a.b(a, ...)`  
> **username_4**: Do you mean for transpiling object-oriented code to a non-OO language (so that `MyClass::MyFunction(int x, int y)` becomes something like `MyClass_MyFunction(MyClass* this, int x, int y)`)?  Or treating these as equivalent *within* one language?  
> **username_3**: @user16217248-OnStrike I thought it was for (metaclass of a)`.b(a, ...)`, but anyways my point still stands, methods aren't "like functions but with a `this` parameter" they're functions with some sugar  
---
## 2 answers
### Answer by username_6 on 2023-07-05. Score: 2 | Accepted answer
Maybe one advantage of having function/method be fundamentally different is, at the syntax level, making it easy to prove that your code doesn't perform method calls.
When reading C++ code, visually one can instantly tell if a call is going to be to a function or to a method:
f(a, b);
a.g(b);

This might be useful to C++ programmers, as they sometimes want to know when a call could go through a vtable, because of the potential cost of pointer indirection.

I imagine that the reason it's like this is, back when C++ was made, OOP was still controversial and not well understood, things like UCS or extension methods hadn't been invented, and people just didn't want to confuse this brand new "method" concept (and its weird virtual/override magic) with a regular function.
Today, it just seems like a good idea to have a way to abstract over whether something is a method call or a function call, because they are so similar.
Maybe I'm completely wrong though.
---
### Answer by username_5 on 2023-07-06. Score: 1
In languages like Java, there are no "free standing" functions. Every function is a method, hence there is no reason to specify explicitly that you are calling a method.

If there are both methods and "free standing" functions like C++ or Python, `this.call()` looks like a useful way to show that the method is being called. However developer that defines and then calls mostly methods, not functions, may anyway prefer to mark explicitly that this is a free-standing function rather than the method call. This can be done by explicitly specifying the namespace: `my_functions::my_function(x)`.
---
