Should 'Component' Be 'Provider' in Blanket Provider Delegation?

[Mota-Link]

Hello @soareschen! Thank you for proposing such an excellent design pattern! I've carefully studied the Terminology and Core Concepts sections of your book and feel this is a highly promising new technology.

However, I have a question about one detail:

In the Linking Consumers with Providers chapter, you state:

"In context-generic programming, we use the term component to refer to a consumer-provider trait pair."

But in the Provider Delegation chapter, you use a blanket implementation to implement StringFormatter for the PersonComponents type. The code is written as:

impl<Context, Component> StringFormatter<Context> for Component
where
    Component: DelegateComponent<StringFormatterComponent>,
    Component::Delegate: StringFormatter<Context>,
{
    fn format_to_string(context: &Context) -> Result<String, Error> {
        Component::Delegate::format_to_string(context)
    }
}

I notice this impl block defines two generic parameters, where Component represents PersonComponents. In my understanding, PersonComponents isn't actually a Component (as defined by the consumer-provider trait pair), but rather an aggregated provider.

Should this blanket implementation instead be written as follows?

impl<Context, Provider> StringFormatter<Context> for Provider
where
    Provider: DelegateComponent<StringFormatterComponent>,
    Provider::Delegate: StringFormatter<Context>,
{
    fn format_to_string(context: &Context) -> Result<String, Error> {
        Provider::Delegate::format_to_string(context)
    }
}

[soareschen]

Hi @Mota-Link, thank you for your support! Yes, you are right that it is probably more appropriate to name the type variable as Provider instead of Component. The terminology wasn't quite set while the book was written, and I will try updating it later.

In any case, you might still see the terms "components" and "providers" being a bit overloaded even today. The term "component" is a bit of a catch all phrase in CGP to capture all different ways to organize code via common interfaces. If we want to be pedantic, we could qualify the specific use, such as the component name (i.e. the name struct), the component implementation (i.e. the provider), and the component interface (i.e. consumer and provider traits).