Lib.rs

用于在组中工作与 Resource 的原型。

初始 PR

用法

use bevy::prelude::*;
use bevy_proto_resource_tuples::*;

#[derive(Resource)]
struct ResourceA;

#[derive(Resource)]
struct ResourceB;

#[derive(Resource, Default)]
struct ResourceC;

#[derive(Resource, Default)]
struct ResourceD;

fn main() {
    App::new()
        .insert_resources((ResourceA, ResourceB))
        .init_resources::<(ResourceC, ResourceD)>()
        .run();
}

动机

随着 Bevy 0.10 和即将推出的 0.11 版本的发布，现在可以使用 add_systems 一次性添加多个系统，而不是多次调用 add_system。同样，正在进行更改，以便一次性添加多个插件。

正如那些接口被改变以最小化调用一样，init_resource 和 insert_resource 调用也可以被最小化，以使接口保持一致。

这有点有争议；主要关注的是，通过分组资源，它以某种方式暗示资源形成“组”，而不是作为独立的对象。这与系统组不同，在系统组中，有操作是针对系统组的，而没有任何操作是针对资源组的，因为它们是各自独特的数据片段。

有些人认为 add_systems 只是一个工具，用于处理具有共同属性的系统组（然后为独特的系统单独调用），而其他人则认为它是一个批量添加系统的工具。

实际上，没有任何阻止任何人以这种方式使用 add_systems 的东西。但从事批量调用和降低 LOC 的角度来看，缺少 insert_resources 和 init_resources 感觉相当不一致。此外，如果添加了这些方法，用户仍然可以像以前一样进行单独调用。

tl;dr：这些方法的好处是，它们带来了一致性和可用性，同时不会阻止用户以旧方式做事或混合感觉合适的样式。

tl;dr for the tl;dr: 更多的用户自由。

局限性

由于这个原型是一个独立的包，我无法实现基例（P0）的 trait，因为孤儿规则。因此，当处理单个资源时，必须调用 init_resource/insert_resource。

模式

以下是一些由这些更改启用的模式。它们是否有用，由用户在实践中发现。无论如何，这些模式都非常专业，但也许它们有一些用例。

// It's now possible to init many resources and get their ids all at once.
let [a, b, c] = world.init_resources::<(A, B, C)>();

// It's possible to create type aliases for multiple resources.
type MyResources<T> = (Foo<T>, Bar<T>);

app.init_resources(MyResources<i32>);