Petition to undeprecate random primitives

[AustinGil]

In an older version, many of the methods on faker.random that return primitive values were deprecated and moved to faker.datatype. I never understood the reason, and I'd argue that restoring them is better developer experience.

• When trying to generate a random value (ie Number), it's more intuitive to go to faker.random
• Using random is better for intellisense because faker.datatype clashes with faker.database. It's much nicer to just type "faker.r" then tab.
• It feels to me like faker.random and faker.datatype serve the same purpose of grabbing fake primitives.

I'm bringing some of my own bias and assumptions here, so I reserve the right to be totally wrong, but I thought I would mention it in the spirit of trying to make this library better.

[ST-DDT]

FFR: This was added in 7ad22c2 v5.5.0

The actual issue is lost to time.

Currently the helper, random and datatype modules are kind of ambiguous.
So I consider removing datatype to be a viable solution, not sure what the other maintainers think though.

[ST-DDT]

I found the original content in this event history: Marak/faker.js - Github Event History

Unfortunately, it does not contain a specific reason for that change.

[ST-DDT]

We created a discussion on how to improve on this: #805

[Shinigami92]

When we bring stuff from datatype back to random, I think we should use new names like:

• datatype.number => random.int (or random.nextInt? This would align with some other languages like Java 🤔)
• datatype.float => random.number

[ST-DDT]

I think moving it to individual modules (strings/numbers) might provide a better developer experience, because first you select what you want and then you have all the variations available for use.

[Shinigami92]

I think moving it to individual modules (strings/numbers) might provide a better developer experience, because first you select what you want and then you have all the variations available for use.

Where would you put boolean, hex, datetime and uuid?
I think functions like array and json can be removed because I don't know which use-case they fulfill 🤷

[ST-DDT]

• Datetime delete
• uuid -> string
• hex -> string
• boolean can remain in random or helpers
• array and json/object/record should be modified and may be moved to helpers: array( numOrRange, elemSource()), ...

[pkuczynski]

I can see the discussion going on here and in #805 - this is a bit confusing. Maybe we should close this issue and focus on the discussion only, which should then be spit into smaller issues?