Explicitly named components

[s1gtrap]

Component names are derived from the type. I propose a way to specify a component name with any generic type. This would lessen pollution (Position and Velocity components can, for example, be boiled down to a single Vector struct) whilst easing integration with other software. For example, I recently found myself doing this:

pub type SpriteId = Uuid;
world! {
    components SpriteId;
}

Uuid isn't very descriptive in and of itself, but that's the type I was given. This could be boiled down to (keeping it rusty with rust's own fn parameter syntax)

world! {
    components sprite: Uuid;
}

or, for variations sake, getting Ruby up in hier,

world! {
    components "sprite" => Uuid;
}

@hannobraun thoughts?

[mtsr]

Personally I'm a big fan of explicit type declarations. That way components like that are defined separately just like struct components.

[hannobraun]

Once upon a time, the world! syntax was more complex than it is today and it actually was possible to explicitly specify the name for various things, although I don't remember if components were among them.

Having to explicitly specify names had disadvantages: I was using Rustecs in a multiplayer game which had three different world declarations: For server-side data, for client-side data and for the common data that was transported between them. This required a lot of code duplication, since everything that was explicitly specified had to be repeated in all three places.

So back then the implicit names were a big advantage (at least in the multiplayer use case), however, nowadays the syntax is a lot simpler then it was back then, so adding the feature you propose would have less of an impact.

That said, I don't quite see the point. You can, as you pointed out, control the name via a type declaration. I like this, since it uses well-established Rust features to achieve the goal without complicating Rustecs. What advantage do you see in adding explicit support for this to Rustecs?

To summarize my position:

• It can be done
• I don't see the point
• But I'm certainly willing to be convinced by your arguments :)

[s1gtrap]

I should've added that I was thinking of making it optional, just like in a function declaration (where the type is derived if not specified). Deriving the component name from the type is good in most cases (obviously!). But it would be nice to have the option, if for instance you're wanting to integrate with PistonDevelopers/sprite which already defines a Sprite struct and uses the Uuid to refer to these. Having a Sprite component then gets complicated for no real reason.

[hannobraun]

The question still stands: What would that achieve that can't be achieved with a type declaration now? Obviously the syntax would be different, but is that worth the added complexity?

[s1gtrap]

Nothing! But sometimes, using a type declaration is cumbersome or redundant. I think something like this is necessary for clean code - like I've mentioned, you need to get creative when dealing with namespaces.

Essentially what this boils down to is that you don't always need a type declaration associated with every component, and that making that type declaration can be dodgy at times (when it shouldn't).

The level of complexity surely depends on the implementation, I'm already messing with a few different ideas (it's very doable:)).

But yea, I might be off on a wrong track. I've only been missing this once thus far.

[hannobraun]

You know what, let's do it. I'm still not convinced we need it, but it seems important to you, so if you're willing to implement it, I don't see a reason to stand in the way :)

I do agree that the implementation wouldn't be very complex, and the "Rusty" syntax you proposed does look nice.