Naming decision on traits and derive macros

[LasseRosenow]

When reading the sea-orm api I got a bit surprised about the naming choices of some Derive Macros and Traits.

In general for rust it is common to name Derive Macros without including the derive word. Because that information is already implicitly done by the derive() part see:

#[derive(Copy, Clone, Debug, EnumIter, DeriveRelation)]
pub enum Relation {}

You may have already noticed, that sea-orm stands out with its DeriveRelation macro. So this looks somewhat inconsistent and confusing I think. Also sea-orm is not even consistent within itself with for example FromQueryResult not having the Derive part.

The same goes for Traits, where some sea-orm traits end with Trait like ConnectionTrait while others do not like StatementBuilder. And also in general it is usually not common for traits in rust to have a Trait suffix.

So I would be interested, what the rationale behind those api decisions is, or if it just happend to be like this or if there are any plans to clean up the api if you think that would make sense.

[tyt2y3]

First of all thank you. You raised lots of good points actually.

I think the rationale is "no one name stands for two things".

As for why macros starts with Derive. I am actually confused for why a symbol in Rust can stand for both a trait and a macro at the same time and there is no way to use only the trait but not the macro when importing / re-exporting.

Similar cause for other things, usually because there were already a thing named Connection so the trait that describes it's behavour becomes ConnectionTrait. For StatementBuilder I guess the Builder suffix is a hint for being a trait, and same for things like IntoXXX or TryFromYYY, those are conventions (from the std library) that the symbol is a trait.

But I agree that it seems inconsistent in general, and some naming changes will be welcomed where appropriate.

[LasseRosenow]

As for why macros starts with Derive. I am actually confused for why a symbol in Rust can stand for both a trait and a macro at the same time and there is no way to use only the trait but not the macro when importing / re-exporting.

Yes indeed that is some interesting design choice, but it seems to be common to have the trait and the derive macro that would be used to derive the trait to share its name see: Copy, Clone, Debug etc.

Similar cause for other things, usually because there were already a thing named Connection so the trait that describes it's behavour becomes ConnectionTrait. For StatementBuilder I guess the Builder suffix is a hint for being a trait, and same for things like IntoXXX or TryFromYYY, those are conventions (from the std library) that the symbol is a trait.

Ah that makes sense, having issues with other types that have already taken the name is a bummer of course :D