Optional Order parameter for GroupAttribute

[Preliy]

This PR introduces an optional int order parameter to the existing GroupAttribute, allowing inspector fields to be grouped and drawn in a defined sequence. Previously, reflection order could lead to unpredictable group ordering when fields are spread across base and derived classes.

Usage Example:

public class GroupOrderTest : MonoBehaviour
{
    [Group("Group3", 30)]
    [SerializeField]
    private float _valueFloatGroup3;
    
    [Group("Group3", 30)]
    [SerializeField]
    private string _valueStringGroup3;
    
    [Group("Group2", 20)]
    [SerializeField]
    private string _valueStringGroup2;
    
    [Group("Group1", 10)]
    [SerializeField]
    private float _valueFloatGroup1;
    
    [Group("Group1", 10)]
    [SerializeField]
    private string _valueStringGroup1;
    
    [Group("Group2", 20)]
    [SerializeField]
    private float _valueFloatGroup2;
    
    [Group("Group3" , 30)]
    [SerializeField]
    private bool _valueBoolGroup3;
    
    [Group("Group2", 20)]
    [SerializeField]
    private bool _valueBoolGroup2;
    
    [Group("Group1", 10)]
    [SerializeField]
    private bool _valueBoolGroup1;
}

Inspector:

[paq]

Thanks for the contribution, and I’m sorry this PR has been left without a review for so long.
I’ve recently joined as a maintainer and am reviewing the existing pull requests as part of restarting maintenance of the project.

The underlying issue addressed here is valid: group ordering should be deterministic and should not depend on reflection discovery order.

However, I don’t think adding an order parameter to the group attributes is the right API design. Alchemy already has [Order] for controlling Inspector ordering, and introducing a separate ordering mechanism for groups would create overlapping concepts and expand the public group API unnecessarily.

If you’re still interested in contributing this improvement, would you be willing to revise the implementation to use the existing [Order] attribute instead? For example:

[Group("Group1"), Order(10)]
[SerializeField]
float value;

This would solve the original ordering problem while keeping a single, consistent API for ordering Inspector elements.

Thanks again for identifying the problem and contribution!

[paq]

I’d like to revise my previous review comment. Group ordering and member ordering are separate concerns, so giving group attributes their own order value is reasonable. I’m withdrawing my earlier suggestion to reuse [Order].

I plan to make the remaining adjustments on my side and merge this PR. Thank you for the original proposal, and sorry for the confusion.

[paq]

Thank you again for identifying this issue and providing the initial implementation.

I’ve opened #154 with some adjustments to the implementation while keeping the original approach of giving groups their own order value.

I’ll continue the work and merge the updated implementation through the new PR. Your contribution is credited in its description, so I’m closing this PR as superseded by #154.