Are methods more than sugar?

[mindplay-dk]

I was wondering, is there any real difference between methods and functions in V?

It doesn't look like V really has objects or method tables or anything like that? By the looks of it, methods are just functions with a different call syntax?

If so, why are methods even a thing?

Wouldn't it make more sense to just allow any function to be called using method call syntax for the first argument?

Then it would be just a choice if you use one syntax or the other - the functions would all just be functions with no special syntax in the declaration, and no constraints on the call syntax.

Is there a reason for methods beyond syntax?

[JalonSolov]

Because similar to class methods in OOP, V's methods are tied to the type.

Yes, of course you could use regular functions, but for example if you had a method that applied to strings, and a same-named method that applied to ints, to use regular functions instead you would either have to have a generic function that figured out which type it was called with, or you would have to have 2 differently named functions to handle the different types.

It really is just a different way of doing things, but it can lead to much cleaner syntax.

[Wajinn]

Prefer V's present way, because it does offer more clarity and readability.

[mindplay-dk]

I'm still wondering about this. 🤔

Because similar to class methods in OOP, V's methods are tied to the type.

Are they?

According to the manual:

V doesn't have classes, but you can define methods on types. A method is a function with a special receiver argument. The receiver appears in its own argument list between the fn keyword and the method name. Methods must be in the same module as the receiver type.

And based on what you said here:

...to use regular functions instead you would either have to have a generic function that figured out which type it was called with, or you would have to have 2 differently named functions to handle the different types.

It looks to me as though V uses the type as part of the method's identity - but not really for anything else.

But that seems unnecessary? I mean, V is statically typed, so the type is attached to the symbol - it has the information it needs to resolve the call, doesn't it?

Let's take a practical example of potentially ambiguous methods: array.reverse and string.reverse.

nums := [1, 2, 3]

println(nums.reverse()) // [3,2,1]

chars := "123"

println(chars.reverse()) // 321

What would be the problem with allowing the following?

fn my_reverse(a []int) []int {
	return a.reverse()
}

fn my_reverse(s string) string {
	return s.reverse()
}

nums := [1, 2, 3]

println(nums.my_reverse()) // [3,2,1]
println(my_reverse(nums))  // [3,2,1]

chars := "123"

println(chars.my_reverse()) // 321
println(my_reverse(chars))  // 321

If this looks like overloading, it isn't - it's a semantic change, in which the first argument of any function becomes a part of the function identity, just as it does with the current function declaration syntax.

There's no ambiguity and no guesswork involved for the compiler here - this semantic change would make declarations like fn f(x X) X and fn (x X) f() X identical in meaning. (as such making the method declaration syntax obsolete.)

In terms of call semantics, "method calls" and "function calls" in V are both just function calls, right? As per the manual, "a method is a function with a special receiver argument". That's it, the call semantics are no different, I think?

The difference is how the functions are looked up at compile-time - method calls use the type and the function name, whereas function calls use only the function name.

The type + name identity approach is actually stronger. Why not apply it everywhere?

[MatejMagat305]

Well first g++ translated class into struct and method into functions so in the end every class is syntax sugar, in theorical it would be working equal, but in practical it would be adition work to compiler pass argument..., and it would be litle bit confusing fir programator now I can play to OOP and everybody from OOP will understand and they will be thinking that is OOP without knoledge backend and the last think in future will be able allow (in theoreticaly) play with visibility ...

[Wajinn]

If so, why are methods even a thing?

The advantage of how V does it, is also the clarity and readability it provides. The method is clearly assigned to a struct, even if the name of the methods are the same.

If the person doesn't want to assign methods to structs, but wants parametric polymorphism, sum types and generics can be used with functions in V.

[mindplay-dk]

OOP Familiarity: yes, I don't think you lose that by allowing even more functions to be called as methods? And not everyone is looking for OOP - the qualities of functional programming definitely has more mind share today than it did even a few years ago. Unifying functions and methods would cater to both camps.

Clarity and readability: I think this argument is debatable. When you call a method defined in some other file, it's not immediately obvious where that method comes from or why it's callable. Explicit imports are arguably more ceremonious, but generally improve clarity and readability: if you're looking at just the one file, you're going to see, at the top of the file, where any functions come from. With good IDE support, adding import statements is easy, and the resulting source files can be read and understood more independently.

For what it's worth, Nim has this feature and this decision has worked out very well for the language - it has some well-known minor limitations, but (as argued) I think having to explicitly import your dependencies is "a good thing" for readability.

You might should take a look at Nim's codebase before dismissing the idea - in my opinion, it's very elegant, explicit, and readable* 🙂

* if you can see past the rest of Nim's syntax to this particular feature - arguably, much of the rest of the language isn't simple and looks more like a "systems programming language" than an "application language"...

[Wajinn]

At some point and level, it can come down to preference. So we may not be talking about what is better, but rather what we prefer. It's like in some other threads where people preferred whitespace/off-side rule indentation to that of C-like languages. Some prefer that style of indentation, while many others don't. Furthermore, name dropping language preferences on the forums of competing languages usually doesn't go well. It's like going to a C++ or Nim forum and telling them you prefer some other language or some feature from it, then get surprised there is push back or people think differently. Though it's totally understandable to have a discussion, as a prelude to a feature request or just to see what others might think.

The other aspect about this, is that the way V does methods is not arbitrary, but is reflective of a more fundamental philosophy with a significantly long history, that can even be traced back to Nicklaus Wirth. The creator of V mentions in the documentation that he was influenced by Go and Oberon. If the matter is studied further, Oberon-2's way of doing methods directly influenced Go, and of which has strongly influenced V. Consequently, V is configured more to be a descendant, alternative, and complimentary to Go and C.

[mindplay-dk]

I'm not "name dropping" Nim. I don't use it. I don't even have a preferred language.

I was just pointing at an interesting feature that might explain the concept better than I could.

I think this is a bit more important than bikeshedding tabs vs spaces.

Just trying to define and discuss a feature. Why the defensive attitude?

[medvednikov]

fn my_reverse(a []int) []int {
	return a.reverse()
}

fn my_reverse(s string) string {
	return s.reverse()
}

This would also require function overloading, which is a terrible idea. It slows down the compiler a lot, complicates the language, makes interop with other languages (primarily C) almost impossible, and makes large code bases much less readable.

V and Go have been designed to have no function overloading.

[InspColumbo]

I can understand your arguments very well. Every design decision has its pros and cons, and it may be too late to make such fundamental changes, regardless of whether the programming language might attract more users or fewer as a result. Nevertheless, I think it is important to make such considerations so as not to miss opportunities. As said before, once the 1.0 release has happened, such changes can realistically no longer be made.
And sorry mindplay-dk for hijacking your thread for a short discussion. :)

[mindplay-dk]

Sorry, I still think you are wrong., mindplay, ...from Wikipedia: Multiple dispatch or multimethods is a feature of some programming languages in which a function or method can be dynamically dispatched based on the run-time (dynamic) type OR, in the more general case, some other attribute of more than one of its arguments.

"more than one of its arguments" - not what I'm proposing.

So you're proposing keeping the old syntax, but also add a way to do methods via functions. That's against V's one way rule

I'm only suggesting you keep the old syntax for backwards compatibility - v fmt could handle the migration to a single syntax.

Such late changes would wreck V as we know it

This won't wreck anything. You would run v fmt and everything would work as before.

any supposed advantage seems more like conjecture and unproven beliefs

I don't think homogeneity in languages is a controversial principle? If one concept is enough to satisfy one requirement, then having one concept is objectively simpler than having two concepts for no practical reason.

In terms of superficial syntax, the supposed advantages are (1) all function declarations look the same, making the language easier to read and write, and (2) function or method style syntax can be chosen based on what makes the code easier to read.

The more subtle advantage is you effectively decouple the syntax from architectural decision making: you won't be tempted to choose a class just because chaining method calls looks nicer. If a method call returns a different type, you won't need to break your call chain, introduce extra variables, or wrap a call chain in a function call - you can break or continue call chains based on what is easier to read, or what best describes the problem/solution.

Which of the following more clearly describes the order in which the functions and methods are actually called?

1. name.split(" ").map(it.runes()[0].str().to_upper() + it.runes()[1..].string().to_lower()).reverse().join(", ")
2. reverse(split(name, " ").map(to_upper(it.runes()[0].str()) + to_lower(it.runes()[1..].string()))).join(", ")

The first form describes in a left-to-right reading order the steps that are actually applied - whereas the second form requires you to raise parens and scan back and forth to make any sense of it.

This is likely one reason why V itself prefers methods over functions for things like arrays and strings - but when you start adding your own functions that operate on strings or arrays (or any type of object outside your current library) you get some mix of (1) and (2) and readability suffers.

This change can fix that.

@medvednikov minor sidetrack

Without having looked at V's source code for string and array methods, I would guess at least some of these are not in fact methods, internally? Correct me if I'm wrong, but I would guess a string is not in fact an object, and you had to jump through some hoops to make the compiler "pretend" like strings or arrays actually have methods? If so, a semantic change might even simplify some of V's internal code.

Again, I'm not a language engineer, and I don't know V's internal codebase, so I can't say if this change creates other challenges. But please don't dismiss the idea without giving it due consideration. It's quite a liberating feature, in my opinion - it removes a whole class of problems and considerations that most hybrid OOP/functional languages suffer from, so I think, by removing some mostly arbitrary architectural choices and decision making constraints from the developers mind, it aligns well with V's focus on simplicity.

(Of course barring it doesn't complicate things considerably for V's compiler internally, as I understand that simplicity is a priority both within the language and the language-implementation itself.)

[medvednikov]

Correct me if I'm wrong, but I would guess a string is not in fact an object, and you had to jump through some hoops to make the compiler "pretend" like strings or arrays actually have methods?

They are simple structs with simple methods:

https://github.com/vlang/v/blob/master/vlib/builtin/string.v#L44

But please don't dismiss the idea without giving it due consideration.

we're always open to all ideas, and not dismissing; I have to do more research to understand this issue better

[InspColumbo]

To be honest, I think mindplay-dk has a very good and valid point with the readability of the dot notation.
However, I still think that if such a change, which would equate function and method calls, is actually implemented, the whole OOP concept in V would become obsolete as well.
I also think that this would give the programming language the decisive advantage over other languages. Just think about it. This would massively reduce the complexity, but the advantages would remain.

[mindplay-dk]

Well, V is already invested in OOP with features like access modifiers and interfaces - obsoleting OOP this late in the game would probably break too many things and might not be entirely realistic.

You don't necessarily have to unify functions and methods to address the syntax fluency issue either - there are at least two other options:

1. Just adding method-style function call syntax: leave methods as-is (offering struct access modifiers and interfaces) but allow functions to be called with the first argument. Similar to C# extension methods but minus the multiple dispatch. This would allow name collisions between methods and functions, so methods would probably need to "win" - the big drawback is, adding a new method could break existing code calling a function by the same name. So this isn't super elegant. But it's a much smaller change.

2. Adding some sort of pipeline operator, another language feature adding a distinct "method-like" alternative calling syntax for functions. This avoids the problem with naming collisions. And it's definitely a much smaller and simpler feature - it's a small syntactic sugar intended solely to solve the syntax fluency problem. It's not a breaking change in any sense, and it's effects are entirely local to the expression.

And just my opinion on the mentioned pipeline operator proposal for JS: as you can see from the proposal, they want this operator with the additional % syntax to do more than just passing the left-hand side of the operator as the first argument. Personally, I don't think that's necessary - if the idea with this syntax is to improve readability, I'm not sure if these expression-like-but-not-quite-expressions do more harm or good. It's common for functions to accept the "subject" as the first argument anyway.

Arguably, both of these approaches add a bit of complexity (more semantics or more syntax) in favor of improving syntax fluency - whereas the idea of unifying functions and methods tries to remove some of the complexity from the language model.

Personally, if I was designing a language, I would definitely want the homogeneous functions and methods - but of course V already has an ecosystem and a userbase to consider. It would be awesome if there was some way to introduce this change progressively, but I also recognize this might not be easy - working around (preserving) access modifiers and interfaces is not something I can offer a solution to, not off the top of my head. Probably something a language engineer would need to weigh in on. 😊