Make api application consistency ... So Locale would become Locale()

[mdmoura]

Hello,

I was checking the following:

.RuleFor(x => x.Locale, y => y.Address.Locale)
.RuleFor(x => x.Latitude, y => y.Address.Latitude())

I think that, for consistency, a method should always be used, e.g., Locale()

And this could be an extending point of Bogus ... For example:

public static Locale(this IValueResolver resolver) {

}

So all API options would be an extension of an "IValueResolver" ...

Having, for example, a Hacker property in Faker class seems kind of strange ... Maybe it should be an extension or maybe Faker could be a partial class to allow adding more properties as a way to extending it ... Well, not sure if this is the best option. Just an idea ...

Thanks,
Miguel

[bchavez]

Hi Miguel,

The Faker class is meant to be used by Faker<T> as a Facade over the data sets imported from faker.js. This is why most of the y.DataSet are defined as properties. The methods on data sets such as y.DataSet.Method() has a direct counterpart to a faker.js JavaScript method. I would like very much to keep these APIs consistent with faker.js as much as possible.

With this in mind, y.Address.Localeis a property value on a DataSet and is a Bogus/C# concept. Additionally, y.Address.Locale() method isn't found on faker.js:Address.Locale(). I hope this explains some API design decisions.

[mdmoura]

Hi,

Yes, it makes sense now that you explain the faker.js part.

Thanks