A paper [1] describes 2 issues with traits (and a suggests a solution,
but that's not what's bringing me here) : statelessness and lack of
visibility control.
In the proposal, the statelessness is taken care of in an interestingly
elegant manner: implementing the traitface ("intraitface"? nah, that's
pretty horrible) for a given type. The instance of some type contains or
rather "is" the state.
As far as I can tell, the visibility control issue is not taken care of.
What it means is that when a trait is composed of other traits, the
instances of these traits have every single method of all the traits.
This doesn't help in defining well-encapsulated objects since it may
leaks implementation details (of "low-level" trait functions)
About conflict resolution
"we might want to do that eventually, but we can punt for now and just
do what Rust already does if a type implements multiple interfaces that
define a method with the same name -- that is, raise a compile-time
"multiple applicable methods in scope" error."
Consider the following case:
// Some library(ies) provide t1 and t2
trait t1{
fn foo() -> ()
}
trait t2{
fn bar() -> ()
}
// Your own code defines t3
trait t3 < t1, t2{
}
One day, the t1 author adds a 'bar' method. When you want to update your
dependency, if the language doesn't provide support for conflit
resolution, then your program stops compiling and any solution you can
come up with involves messing around with third-party code. This is
unrealistic. I shouldn't have to mess with third-party code to fix
problems that arise in my own code.
It has to be noted that in absence of visibility control mechanisms,
conflicts are even more likely, so the problem I've just described has
greater likelihood to occur.
I hope this example was convincing enough to prove that conflic
resolution should be part of the first trait iteration.
David
Le 07/07/2012 00:04, Lindsey Kuper a écrit :
> Two of the changes mentioned in the development roadmap that Graydon
> sent out earlier this week were "Extend interfaces to full traits" and
> "Enforce implementation coherence". Those are addressed by this
> proposal for unifying traits and interfaces:
>
> https://github.com/mozilla/rust/wiki/Proposal-for-unifying-traits-and-interfaces
>
> This work is already starting to get underway, as evidenced by
> occasional references to "traitfaces" that you might have seen go by
> on IRC and Twitter (e.g.,
> https://twitter.com/littlecalculist/statuses/217867708212051969)
> (don't worry, we're not actually going to call them that). But I
> haven't made any announcement of the proposal here on rust-dev yet, so
> here it is. Feedback welcome!
[1] http://soft.vub.ac.be/Publications/2009/vub-prog-tr-09-04.pdf
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
