TASK: Code style adjust 5 internal usages of Object::none() to ::createEmpty()

[mhsdesign]

We had the discussion again how to name an empty object and for normal collections we used createEmpty() in the past (25 present definitions) and should continue to do so. The use of none() snuck in lately via the subscription engine.

#5463 (comment)

Upgrade instructions

Review instructions

Checklist

• Code follows the PSR-2 coding style
• Tests have been created, run and adjusted as needed
• The PR is created against the lowest maintained branch
• Reviewer - PR Title is brief but complete and starts with FEATURE|TASK|BUGFIX
• Reviewer - The first section explains the change briefly for change-logs
• Reviewer - Breaking Changes are marked with !!! and have upgrade-instructions

[bwaidelich]

Personally I disagree with a rule to use the same name everywhere because named constructors allow us to make the code more speaking and that is dependent on the specific type.
For example ContentDimensionConstraintSet::createEmpty() makes sense to me but CommandHooks::none() is easier to comprehend than CommandHooks::createEmpty()..

However, I get the reasoning about being consistent too, and wouldn't block this ofc

[kitsunet]

What @bwaidelich said, I think it's important that we write speaking code as much as possible.

[mhsdesign]

hmm jup i do understand that point too... and it seems we have a third player too public static function empty(): self which is used in a few minor places.

These are the existing createEmpty usages and there seems to apply no rule to them.

From what seems natural classes ending with *Set or *Collection are a candidate for createEmpty
Whereas collections indicated just by the plural form *s are predestined for none()

Seeing at the existing usages this rule does not apply at all:

And i think any rule would not be able to be carried out consistently because why should i rename the factory when i change the name to include Collection as suffix or not.

I made this pr because it targets only internal factories ... and to enforce we have a unique way of instantiating empty things.
I think we earlier agreed to name things createEmpty vs empt because someone argued it was important to have the "create" notion in the wording. Now "none" also contradicts to that ... and i think it was you who came up with favouring "createEmpty"

After all it really doesnt matter that much i just like doing random things have good evening bye.

Plural S

- CommandHandler/Commands::createEmpty()
- Dimension/ContentDimensionValueVariationEdges::createEmpty()
- Feature/NodeCreation/Dto/NodeAggregateIdsByNodePaths::createEmpty()
- Feature/NodeModification/Dto/SerializedPropertyValues::createEmpty()
- Feature/NodeReferencing/Dto/SerializedNodeReferences::createEmpty()
- Feature/SubtreeTagging/Dto/SubtreeTags::createEmpty()
- NodeType/NodeTypeNames::createEmpty()
- Projection/ProjectionStates::createEmpty()
- Projection/ContentGraph/NodeAggregates::createEmpty()
- Projection/ContentGraph/Nodes::createEmpty()
- Projection/ContentGraph/NodeTags::createEmpty()
- Projection/ContentGraph/Subtrees::createEmpty()
- SharedModel/Node/NodeAggregateIds::createEmpty()
- SharedModel/Node/PropertyNames::createEmpty()
- SharedModel/Workspace/Workspaces::createEmpty()
- Domain/Model/WorkspaceRoleAssignments::createEmpty()
- FrontendRouting/Options::createEmpty()

Suffix Collection / Set ...

- Subscription/SubscriptionStatusCollection::createEmpty()
- Dimension/ContentDimensionConstraintSet::createEmpty()
- Domain/Service/NodeDuplication/NodeAggregateIdMapping::createEmpty()

Others

- Projection/ContentGraph/NodePath::createEmpty()
- Feature/NodeReferencing/Dto/NodeReferencesToWrite::createEmpty()
- Feature/NodeModification/Dto/PropertyValuesToWrite::createEmpty()

[mhsdesign]

i have no hobbies lol

[kitsunet]

I feel like these are two distinct discussions, do we need the "create" prefix which suggests a constructor/factory method, and I feel it's good to have, but $depends, we won't have many static methods outside of static constructors, so it could be implied.

then secondly is the empty/none distinction important?

Commands::empty() vs Commands::none(), obviously createNone makes no sense, which I guess is why we have createEmpty only...

[mhsdesign]

I think we should go with this pr as it really streamlines things. And its really important to note that the things that have custom constructors now are NOT API - the things that are api where maybe a custom constructor would make sense are all named boringly createEmpty. I think its a nice non breaking adjustment so that i can argue in the future we never use none() 😂 !!!