MusicHoard with dyn Trait or generics? #93

New Issue

wojtek · 2024-01-11T23:27:39+01:00

wojtek commented

2024-01-11 23:27:39 +01:00

Basically the undoing of #31

wojtek referenced a pull request that will close this issue

2024-01-11 23:29:28 +01:00

WIP: 93---musichoard-with-dyn-trait-or-generics #94

wojtek added the

chore

label 2024-01-11 23:29:45 +01:00

wojtek commented

2024-01-12 07:28:45 +01:00

https://www.lurklurk.org/effective-rust/generics.html

In summary: prefer generics.

Details:

The balance of factors so far leads to the advice to prefer generics to trait objects, but there are situations where trait objects are the right tool for the job.

The first is a practical consideration: if generated code size or compilation time is a concern, then trait objects will perform better (as described at the start of this Item).

A more theoretical aspect that leads towards trait objects is that they fundamentally involve type erasure: information about the concrete type is lost in the conversion to a trait object. This can be a downside (see Item 19), but it can also be useful because it allows for collections of heterogeneous objects – because the code just relies on the methods of the trait, it can invoke and combine the methods of differently (concretely) typed items.

The traditional OO example of rendering a list of shapes would be one example of this: the same render() method could be used for squares, circles, ellipses and stars in the same loop.
    let shapes: Vec<&dyn Shape> = vec![&square, &circle];
    for shape in shapes {
        shape.render()
    }
A much more obscure potential advantage for trait objects is when the available types are not known at compile-time; if new code is dynamically loaded at run-time (e.g via dlopen(3)), then items that implement traits in the new code can only be invoked via a trait object, because there's no source code to monomorphize over.

None of these are concerns at the moment.

https://www.lurklurk.org/effective-rust/generics.html In summary: prefer generics. Details: > The balance of factors so far leads to the advice to prefer generics to trait objects, but there are situations where trait objects are the right tool for the job. > > The first is a practical consideration: if generated code size or compilation time is a concern, then trait objects will perform better (as described at the start of this Item). > > A more theoretical aspect that leads towards trait objects is that they fundamentally involve type erasure: information about the concrete type is lost in the conversion to a trait object. This can be a downside (see Item 19), but it can also be useful because it allows for collections of heterogeneous objects – because the code just relies on the methods of the trait, it can invoke and combine the methods of differently (concretely) typed items. > > The traditional OO example of rendering a list of shapes would be one example of this: the same render() method could be used for squares, circles, ellipses and stars in the same loop. > > ```rust > let shapes: Vec<&dyn Shape> = vec![&square, &circle]; > for shape in shapes { > shape.render() > } > ``` > > A much more obscure potential advantage for trait objects is when the available types are not known at compile-time; if new code is dynamically loaded at run-time (e.g via dlopen(3)), then items that implement traits in the new code can only be invoked via a trait object, because there's no source code to monomorphize over. None of these are concerns at the moment.

wojtek closed this issue

2024-01-12 07:30:43 +01:00

wojtek referenced this issue

2024-01-12 07:30:52 +01:00

WIP: 93---musichoard-with-dyn-trait-or-generics #94

Sign in to join this conversation.