It's different from everything else because it's a non-overlapping feature :)
But yes, I think being like OO is reason enough to do it. If we didn't have
that, then you'd have to import every method you call. I think that that would
turn off far too many programmers coming from mainstream languages. Almost
every mainstream language I can think of that has methods at all does name
lookup this way. (The main exception in the OO world would be pure
multimethod-based systems, but they aren't mainstream and I personally question
whether they can be in part because of this very issue.) Rust was designed to
be a multiparadigm language, supporting both functional and OO style, and this
feature is an extremely common part of object-oriented programming.
If it helps, this feature is not without precedent. The "search through
associated methods" behavior is the same as Go and similar to Objective-C, with
its @interface/@implementation divide. The "search through traits in scope"
behavior is similar to Scala and C# extension methods.
I don't see the things you mention as warts. They're just consequences of,
well, having methods in the OO sense. Nearly all of these "warts" show up in
other object-oriented languages too. Maybe they're warts of object-oriented
programming in general and illustrate that OO is a bad idea, but as I mentioned
before Rust is designed to support OO.
I shouldn't have been so absolute about not changing stuff--we can and will
change things--but I don't see having to import every method as a positive
change. We discussed it years ago and concluded that it was a non-starter due
to the burden it would impose on everyone.
Patrick
"Gábor Lehel" <[email protected]> wrote:
>On Sat, Oct 19, 2013 at 10:52 PM, Patrick Walton
><[email protected]>wrote:
>
>> I think it's unfortunately too late to overhaul the language like
>this.
>> This will require redesigns of all Rust code in existence.
>>
>> I do like unified function/method call syntax, but I think it can be
>done
>> in a backwards compatible way.
>>
>
>This is up to you and the rest of the Rust team, of course. But in my
>very
>humble opinion, it feels shortsighted to impose backwards compatibility
>constraints at this point. All Rust code in existence is still
>(hopefully!)
>a negligibly small fraction of the code that is yet to be written. I
>know
>there's a desire to get 1.0 out the door as soon as possible, and I
>understand it (I want to be using Rust instead of C++, too!), but if
>Rust
>is still in use years or decades from now, decisions made now about the
>design of the language will echo far louder than whether it was
>released a
>few months earlier or later. I think it would be unfortunate to start
>suffering a C++-like fate sooner than absolutely necessary.
>
>That was a general argument, and it only matters if something is
>considered
>a good idea on the merits. In this case, it seems we disagree about
>that:
>
>On Sat, Oct 19, 2013 at 11:46 PM, Patrick Walton
><[email protected]>wrote:
>
>> I was thinking not. The dot operator should still have special name
>lookup
>> rules: it searches through associated impls and all traits in scope.
>It
>> cannot call anything that is not attached to an impl.
>>
>> This does make functions and methods somewhat less unified, but it
>makes
>> methods feel more like OO methods from a scoping POV. I feel the
>draws of
>> methods are not only that they switch the order of the receiver and
>action
>> but also that they allow functions associated with a type to be
>called
>> without explicitly importing their names.
>>
>
>Aha. That's exactly the thing I don't like, and thought would be
>beneficial
>to change. It's different from everything else for no great reason (is
>being like OO a great reason?), and carries baggage with warts and
>thorny
>issues in it. (Needing special language constructs to write methods;
>normal
>`fn`s feel like second-class citizens; can't selectively or
>rename-import
>methods; can't write method-syntax functions in a different crate
>without
>introducing spurious abstraction boundaries; the whole `impl T {
>fn(&self)
>}` versus `impl &T { fn(self) }` ugliness; traits and generic types in
>paths raise awkward questions; ...)
>
>--
>Your ship was destroyed in a monadic eruption.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity._______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
