Namespacing for clarity

[rpbaptist]

I like Faker because it's useful. I also like generating quotes over lorem ipsum. What detracts from the usefulnes of Faker is this:

• Faker::HarryPotter
• Faker::HeyArnold
• Faker::Hipster
• Faker::HitchhikersGuideToTheGalaxy
• Faker::Hobbit
• Faker::HowIMetYourMother
• Faker::IDNumber
• Faker::Internet
• Faker::Invoice
• Faker::Job
• Faker::Kpop
• Faker::LeagueOfLegends
• Faker::Lebowski
• Faker::LordOfTheRings

Out of this huge list, what I find useful is IDNumber and Internet. When I want to use this list as a reference there's a big list of noise to scroll through.

My suggestion is to namespace these, as such:

• Faker::PopCulture::HarryPotter
• Faker::PopCulture::HeyArnold
• Faker::PopCulture::HitchhikersGuideToTheGalaxy
• Faker::PopCulture::Hobbit
• Faker::PopCulture::HowIMetYourMother
• Faker::PopCulture::Invoice
• Faker::PopCulture::Kpop
• Faker::PopCulture::LeagueOfLegends
• Faker::PopCulture::Lebowski
• Faker::PopCulture::LordOfTheRings

For lorem generators:

• Faker::Lorem::Hipster

For core features:

• Faker::IDNumber
• Faker::Internet
• Faker::Job

This would also handle this naming:

• Faker::Lorem
• Faker::LoremFlickr
• Faker::LoremPixel

Which could be:

• Faker::Lorem::Ipsum
• Faker::Lorem::Flickr
• Faker::Lorem::Pixel

I am happy to make a PR for this, but I wanted to get some consensus on this before I do. I realize this is a breaking change, but this could of course be solved through deprecation.

[Zeragamba]

I think we should keep the namespacing as we have a huge number of generators (~160 !), and there are some cases where it's not exactly clear whats in each generator (as metioned by @justinxreese near the beginning of this issue).

We've already been sending out deprecation notices since the release of v1.9.2 (2019-02-11). I would expect that there would be a lot of annoyance from users if we reversed back to no namespaces.

[stympy]

That sounds like a +1 for releasing v2, which will have plenty of backwards incompatibility, sooner rather than later. :)

[vbrazo]

Namespaces are okay as long as we try to have good generators. I'd prefer to start thinking about the generators that aren't useful.

Contributors should explicitly tell us why they're adding a new generator by giving a use case in the PR description. I think we should add a GitHub template for the PRs and ask for that.

[Zeragamba]

Speaking of good generators, there are a few bad ones that have only one method in them (eg, Faker::Creature::Animal, Faker::Artist, Faker::TvShows::MichaelScott) We could merge some of these into other generators.

[boardfish]

@SpyMaster356 Perhaps single-method fakers could go back into the top-level generator, so we'd get Faker::Creature.animal and Faker::TvShows.michael_scott_quote for example? I can't really say this with full conviction as I get the feeling it's got caveats, but right now I can't think what those might be. Feel free to propose something else.

[PatrickLerner]

I would advocate to delete all the pop culture stuff from the main gem (who needs most of it really? and it just adds a ton of PR where everybody wants to get their list of random things into this gem) and if you really want lord of the rings character names, it can be a separate gem (lotr-faker). But I guess I am in the minority here as people seem to enjoy this.

[boardfish]

@PatrickLerner I imagine this was part of the case for #1539. A project of mine, RemoteRecord will most likely do something like this. I'm choosing to take that approach for a few reasons, but they're also reasons that support Faker retaining its current structure as I'll explain.

It might help to check it out for a bit of context, but I'm hoping my explanations here are framed in a way that can be understood without it. What's important here is that RemoteRecord plugs into any API you need, and that introduces the following differences:

• It's the responsibility of the community, not the base project, to publicize and maintain each individual module. In RemoteRecord's case, this is better because it's often in the interest of companies to have their own developers maintain their RemoteRecord extensions. The same can't really be said for Faker, in which all we're dealing with is text. As long as the writers know the subject matter and are literate, anyone can manage Faker's content library.
• Faker doesn't particularly need to be extended manually by its users since it has such a wide scope already. RemoteRecord (at least right now) will almost always want to be extended manually by writing code in app/lib/remote_record. The next stage from that is having a set of gems like remote_record-github and remote_record-spotify that folks can install as they need. Faker comes with an extensive base scope that makes this unnecessary - changing to that sort of structure, more importantly, would put more friction in the way of using Faker.

[stefannibrasil]

Hey, folks. In an effort to lighten our load as maintainers and be able to serve you better in the future, the faker-ruby team is working on cleaning out the cobwebs in this repo by pruning the backlog. As there are few of us, there are a lot of items that will simply never earn our attention in a reasonable time frame, and rather than giving you an empty promise, we think it makes more sense to focus on more recent issues. That means, unfortunately, that we must close this issue.

Don't take this the wrong way: our aim is not to diminish the effort people have made or dismiss problems that have been raised. If you feel that we should reopen this issue, then please let us know so that we can reprioritize it. Thanks!