Faker: At which point do we break off functionality?

[benpolinsky]

Just curious, at which point does this gem become unnecessarily bloated? I'll admit I added support for placehold.it images, but that seems like a common use case that many users can use, and in a more general fashion than the robot images that were our only option before.

How many people are going to use the Pokemon functionality? What happens when I want to put in car makes and models, or types of food, or specific varieties of berries? At some point, perhaps, if data is unique to your specific application you should be generating it yourself.

Opinions? If this is not the place for this discussion, I apologize. Just something I've thought of numerous times and wanted to put it out there.

[stympy]

I've had this same question many times myself. :) I'm open to suggestions, but I've tended towards inclusiveness, with the main criteria being, "will more than two people find this useful?"

[b264]

I have wondered the same thing. Perhaps there is a way to have a "basic set" of functionality and an "extended set" that isn't loaded until requested, or is pulled from a separate gem like faker-data or something

[benpolinsky]

@stympy makes sense. Definitely tough to draw the line, and I have nothing specific against Pokemon 😄

The more I think about it, the more it seems premature to refactor any functionality.

[baublet]

My 2 cents as a frequent user of this gem: I love the wide functionality. Is being bloated a problem for a gem that is most frequently used in development environments for testing? Even if this gem added megabytes of extra classes and code, it's hard to see a point at which this gem alone slows down anyone's tests.

Perhaps a better idea might be splitting the documentation into something like Core and Extended, where core are the basics and extended are the things like Game of Thrones houses, Pokemon, and so on? This would at least make it easy for new users to get a grasp on the basic features, while not sacrificing the fun, playful breadth of some of Faker's modules.

[stympy]

I have moved the per-class documentation to individual files, which should make the usability of the README better. :) I'm open to the idea of "core" and "extended", too.

In addition, it may make sense (2.0) to combine some of the code (like the various image classes) together.