The signature is fn(&Foo, u8). If that's not in the right order, you can always put it in a closure -- this is not a Rust-specific problem.
> It makes life of web-servers harder.
I don't see why web servers need exceptions. You do have catch_panic if you want to prevent the application from ever crashing; that's what it's for (rewrapping fatal errors at the top level or preventing panics from leaking through FFI)
> To parse JSON with nested objects you need to declare a lot of structures.
Fair enough. I think there was a nested hashmap based JSON library somewhere?
No, caller doesn't care about "self" and should not. It's Rust-specific ugliness and "different order of arguments" is absolutely not the same as "implicit first argument".
I really wonder how it can be unclear.
Iron expect method with signature "Fn(req: &mut Request) -> IronResult<Response>", it means you just can't use any method of instance, because all of them have crappy "&self" in signature (otherwise there is no point to make them methods of some object). And yes, you can add closure wrapper, add "move" keyword and satisfy all "move" requirements. But it's exactly what I'm talking about.
And of course it is. The handle function needs a `Foo` to store state or whatever. If it didn't, you wouldn't have implemented it as a method at all, you would have implemented it as a non-self function (`impl Foo {fn handle(req: &mut Request)}`, which can also be passed directly as `Foo::handle`). Where would the Iron function get this receiver from? You have to pass the receiver down with the function, so you need a closure (anything which is callable and has an associated state, i.e. more than just a function pointer)
This has nothing to do with `self`. It has to do with the fact that methods need a receiver, which is a general fact of life with methods.
So your handler needs a receiver with some extra state that you're using. You would need to pass down the receiver regardless, and the signature doesn't support arbitrary receivers.
This is a problem in Rust and Python, as you correctly noted. It's a worse problem in Java where the stdlib callable doesn't even allow arguments, so you have to implement an interface (FWIW this solution is available to you in Rust too, either directly implementing `Fn(..)` or if Iron decides to accept a special trait instead), which is much more typing. PHP needs you to construct an array thing to make a callable closure, which is arguably just as 'bad' as Java.
C++ has function pointers, but methods don't work as function pointers (since you still need there to be a closure under the hood, and C++ doesn't do that kind of implicit stuff). C++ Concepts seems to have a "Callable" concept, but I didn't look into whether or not it comes with auto-closureifying syntax.
So really the issue has nothing to do with `self` being used for method signatures, it has to do with whether or not `object.method` is automatically turned into a closure. Rust tries to avoid such magic, so it doesn't have this feature. It could, with relative ease, without getting rid of `self`.
Two languages which do seem to do this are Javascript and Go. In Go (http://play.golang.org/p/jsKtkbD7vr), `foo.handle` is automatically turned into a `func(*Request)`, which is even more magical, since IronRun expected a `func` and not an `interface Callable` or whatever.
Javascript does the same, `obj.handle` will auto-create a closure for you.
Yes, it would be slightly neater for Rust to auto-closure `obj.handle`, but this sounds a bit too magical for Rust (which tries to be low level and make costs explicit). This has nothing to do with `self`, and this isn't a problem localized to Rust.
Thank you for detailed explanation.
Any language has some magic. Some languages have too much of magic (like Ruby) and I hope Rust will no go this way. But when magic is about to save couple of lines - I think it's ok, I'm with authors of Java,C#,etc in this term. I prefer to call it syntactic sugar, and to be fair, Rust have examples of such sugar. So in my opinion "sugared" (or magic) "this" keyword inside of method body is more optimal way to send receiver to method - it allows programmer to save lines of needed closures boilerplate.
When you make a decision to include some magic, you have to look at the overall milieu of how it can be used and abused, not just the specific use case that it makes awesome. It may "save a couple of lines" but that's not all it does.
As far as auto-closureifying methods, you might have a lot of people doing things like `let x = vec.len` and getting confusing errors when trying to use `x`, and other errors due to the implicit moving or borrowing of `vec`. Currently when you make such mistakes (which is common) the compiler tells you exactly how to fix it because taking the value of a method is illegal. If this was legal, it may cause errors further down the line which are not clearly tied to this and you can't have reasonable error messages. Additionally there's no way to specify this moving or borrowing, so an arbitrary choice has to be made, which would be implicit and opaque. Explicit closuring is just a few more characters and not a bad price to pay for avoiding this class of errors.
The reason we have explicit `self` (which again, is different from the above and completely orthogonal to the Iron issue) is due to ownership/borrowing again. You want to be able to specify how a method takes its receiver (self/&self/&mut self/Box<Self>). It could be done via extra syntax but that gets uglier, really, and in a language like rust where ownership is important, you don't want ownership implications to be kludgy and confusing. Having a syntax which mirrors argument syntax is really clearer.
is an argument. Maybe I just can't imagine how ugly it would look without "self" argument.
Thank you for explanation. At this point I almost agree with you. Well, I agree, but still can't say "oh, I love that closures boilerplate!" :)
There's nothing Rust-specific about methods having a self argument. All languages with methods have such a thing. I'm really unsure of what your specific complaint is here.
Yes, all languages, though in Rust and Python they are explicit rather than implicit at the definition site. And note that although Rust makes them explicit for technical reasons (allowing you to control the manner in which the receiver is taken), their explicitness in Python is only because Guido wanted people to understand that methods require a receiver parameter in order to operate, a misunderstanding which appears to be the root of your confusion.
Point is "signatures are different". You can't use this function in place where you need signature without &self.
> You're not supposed to
It makes life of web-servers harder.
> Could you expand on this point?
To parse JSON with nested objects you need to declare a lot of structures. When APIs are difficult, people even use code generators.
> It's idiomatic
It's not an argument. What work should work. Idiomatic or not - another question.