What would happen if two types defined a method called, say, "foo", and the
importing module glob imported them both?
Patrick
"Gábor Lehel" <illiss...@gmail.com> wrote:
>On Sun, Oct 20, 2013 at 7:31 PM, Gábor Lehel <illiss...@gmail.com>
>wrote:
>
>> So I very much agree with Patrick. Some aspects of this proposal are
>>> attractive, but it breaks some essential properties of the way
>methods
>>> currently work (and probably can't be adjusted to work around that
>>> without losing most of it attraction).
>>>
>>
>> The main cost would be having to import methods explicitly (or using
>a
>> glob), as Patrick notes.
>>
>
>Now I'm wondering, though: going with my proposal, if the module
>structure
>were just a little bit more fine-grained, I think you could achieve
>basically the same effect as the current system, if you wanted to. If
>the
>convention were to use a module to enclose a type together with its
>methods
>(which is already the case in many places), and you did a glob import
>of
>that module, you would get what you have now: the type and its methods
>would all come into scope. Except you could still import selectively,
>if
>you wanted to, or do things any other way, if you wanted to, and all of
>the
>"warts" I mentioned would still disappear. In a different crate, you
>could
>similarly create a module of "extension methods", which could be
>imported
>together or selectively, if you wanted to.
>
>I don't want to push this too hard if it's past the point of being
>productive, but I'm now even more convinced that this would be a
>beneficial
>change. Types should be types, grouping and scoping should be done with
>modules (Rust's modules are very capable), and traits should be used
>for
>type-based abstraction. I think it would work great.
>
>--
>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
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
