[rust-dev] "Implementation Inheritance" / mixins

Oren Ben-Kiki oren at ben-kiki.org
Tue Nov 12 03:18:31 PST 2013


It does force one to repeat all the members and all the function
signatures, which is (1) pretty tedious and (2) fragile, as making change
to the base would require making the same changes "everywhere".

The reuse-as-macro idea is to automate this process, so changes would
propagate without changing all the places in the code that use the mixin.

Another difference is that if f1 invokes f2, in the manual method, f1 will
invoke the original f2, while in the reuse-as-macro approach, it would
invoke the new f2.

Otherwise, this is basically the same thing, only manual.

Oren.



On Tue, Nov 12, 2013 at 12:46 PM, spir <denis.spir at gmail.com> wrote:

> On 11/11/2013 09:16 PM, Oren Ben-Kiki wrote:
>
>> At any rate, I'm not claiming this is necessarily the best approach for
>> Rust; I'm just wondering, what is the proposed way to address this use
>> case? None of the manual approaches seems very appealing (unless there's a
>> better one I missed).
>>
>
> My preferred approach is explicite derivation. May look like:
>
>     struct S1 {
>         x1 : uint,
>         x2 : uint,
>         x3 : uint = 1,
>         x4 : uint = 1,
>
>         fn f1 () {...},
>         fn f2 () {...},
>     }
>
>     struct S2 [: S1] {      // optional subtyping for polymorphism
>         x1 : uint,          // same field
>         x2 : uint = 2,      // same field, with std value
>         x3 : uint = 1,      // same field, same std value
>         x4 : uint = 2,      // same field, diff std value
>         x5 : uint,          // new field
>         x6 : uint = 2,      // new field,  with std value
>
>         fn f1 () = S1.f1,   // same func,  same value (reuse)
>         fn f2 () {...},     // same func,  diff value (override)
>         fn f3 () {...},     // new func
>     }
>
>     // more structs derived from S1
>
> An advantage is that each new type is completely defined on place; except
> for the body of reused functions, but one still has the signature and knows
> where the body is to be found.
>
> This apparently brings no novel issue and avoids a few know problems due
> to conventional "inductive" or "recursive" inheritance. All methods are
> right here. In theory and practice, I guess, one can well reuse from
> various existing types any suitable method; or more generally any role,
> trait, in ordinary sense of the terms. In case of conflict, the user
> explicitely states which one is intended, and there is no diamond problem.
>
> But the main gain in my view is that this scheme provides very good
> auto-documentation, I guess. I have however no idea of how to implement
> that in a static lang, esp the subtyping aspect (but do think it's no more
> complicated, maybe even less) (I implemented it in Lua, rather easy).
>
> Denis
>
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20131112/9656ddd4/attachment.html>


More information about the Rust-dev mailing list