"Your solution does not match the performance of single inheritance,
because it has virtual method calls for every field access from the
"outside" of the trait."
Sorry, I don't follow.
Access to members from outside of the traits would require accessing the
concrete type. Since the approach I described used source transformation,
then this would just be a normal data member access, as efficient as single
inheritance.
Put another way, there's no difference for member access from within and
from outside the trait; both are interpreted as normal data member access
given the concrete struct (which includes the reused data members somewhere
in it).
pub struct FooS { member: int; }
pub struct BarS { ... reuse FooS::*; ... }
// Gets expanded to:
pub struct BarS { ... member: int; ... }
// Then compiled normally
/* Either inside or outside any trait, doesn't matter */ {
bar: BarS = ...;
bar.member; // Just a normal data member access
}
impl AnyTraitAtAll for BarS {
... {
self.member; // Still just a normal data member access
}
reuse SomeMixin::*; // Doesn't matter, `member` is still just a normal
data member
}
On Tue, Nov 12, 2013 at 9:43 AM, Patrick Walton <[email protected]>wrote:
> On 11/12/13 4:32 PM, Oren Ben-Kiki wrote:
>
>> Ah, thanks. I wasn't aware of that. I should start tracking that RSS
>> feed...
>>
>> I am very concerned that single-inheritance takes the language in the
>> wrong direction. I feel that a more mixin-oriented solution would better
>> match Rust's traits based type system. I posted a comment the blog entry
>> you gave, which I assume is a more appropriate venue than this thread...?
>>
>
> Your solution does not match the performance of single inheritance,
> because it has virtual method calls for every field access from the
> "outside" of the trait.
>
> We don't want single inheritance because we're enamored with Java or
> anything, we want it because nothing that we've been able to come up with
> matches the performance that the prefix property on fields buys you. C++
> code can be very fast for a reason.
>
> We considered Go's anonymous fields but rejected them because they don't
> support virtual methods at the same time as field embedding.
>
> Patrick
>
>
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
