Rename project to Pseudorandom?

[konard]

This will allow not to use explicit namespace reference like System.Random, but just Random.

[uselessgoddess]

No

[konard]

No

Why?

[uselessgoddess]

PseudorandomHelpers::Default is very long

[konard]

Analysis and Recommendation: Should Platform.Random be renamed to Platform.Pseudorandom?

After thoroughly analyzing the codebase and .NET namespace best practices, here's my assessment:

Current State

• The project uses Platform.Random namespace
• System.Random is explicitly referenced 8 times in the code
• No actual namespace conflict exists in consumer code

Key Findings

The namespace conflict concern is not a real issue in practice because:

1. Platform.Random and System.Random are different namespaces
2. Consumers can use using Platform.Random; without conflicts
3. The extension methods work correctly: someRandomInstance.NextUInt64()
4. RandomHelpers.Default provides convenient access to a System.Random instance

According to .NET namespace best practices:

• The current naming follows Microsoft guidelines: <Company>.<Technology>
• The issue would only arise if there was a class named Random in the Platform.Random namespace
• Using fully qualified names (System.Random) is acceptable and commonly used

Recommendation: Keep Platform.Random

Reasons:

1. No real conflict exists - the namespaces are distinct
2. Breaking change cost - renaming would affect all consumers and infrastructure
3. Community feedback - contributors have expressed preference for current naming
4. Usability - RandomHelpers.Default is more concise than PseudorandomHelpers.Default
5. Consistency - follows the established Platform.* naming pattern in the LinksPlataform ecosystem

Alternative Solutions (if needed)

If namespace disambiguation becomes an issue for consumers, they can:

• Use namespace aliases: using PlatformRandom = Platform.Random;
• Use fully qualified names where needed
• Import specific classes: using static Platform.Random.RandomHelpers;

Conclusion: The current Platform.Random naming is technically sound and follows .NET conventions. The perceived conflict doesn't create actual problems in practice.