Add ability to override custom types in auto-generator

[cmeeren]

It would be great if the user could specify overrides for any complex type they desire. For example, say Customer is a type that has a field of type Customer list (sub-customers of the current customer). This is recursive and (currently) needs a specifically designed generator to avoid stack overflow. Say then that I want to generate an Order type which, among other things, contains a Customer, then I'd want to just say auto<Order>(...) and somehow specify that I want Customer objects to be generated using my specific generator, and otherwise the defaults are fine.

I'm not sure how to do this though, or if it is easy/feasible/possible.

[cmeeren]

Any thoughts on this?

[moodmosaic]

I apologize for the delay, I've been busy. I'll get back to this soon. /cc @jystic

[moodmosaic]

There should be quite a few ways of doing this, and I think I'm not convinced with any of them:

• Pass a dictionary in the auto function, then have it lookup on the dictionary, and if the type is there, use that type from the dictionary
• F# interfaces and object expressions
• Emulate typeclasses like FsCheck does which is being under discussion in v3
• Statically Resolved Type Parameters
• Propositions as Types

[moodmosaic]

I'd start looking for the most type safe approach which immediately excludes the emulation of Haskell typeclasses and the dictionary lookup.

[cmeeren]

I haven't thought too hard on this, but recursively auto-generating custom types seems inherently un-typesafe to me. How could it be made type-safe? Could you share an example?

[cmeeren]

Hmm, I just thought of another way to solve the specific problem of stack overflow when auto-generating recursive types (which is the main reason I wanted this override functionality in the first place).

We can add a recursionDepth: int parameter to the config. An inner auto function can get passed a Map<System.Type, int> that describes how many times the given type has recursed. When it reaches the recursion depth, it will as far as possible stop generating these (e.g. None if it's an option of that type, or empty list if it's a list of that type).

For example, say we have a Customer with a list of child customers also of the type Customer. We generate this with a recursion depth of 1. For each sub-type it generates, it checks the map to see how many times it has recursed. Initially of course, the map won't contain the Customer type key (i.e., recursed zero times). So now it adds Customer to the map with the value 1, and generates a list of sub-customers, passing along the modified map. When this auto call gets to the same Customer list generation, it'll see that Customer has recursed once, and the recursion limit (from the config) is 1, so it'll generate an empty list.

What do you think?

[cmeeren]

Nearly finished with an implementation of what I described above. Seems to work brilliantly. Will create a PR when I'm done, need to test it thoroughly.

[moodmosaic]

On mobile right now, but looking forward to your PR.

[dharmaturtle]

I'm interested in this feature. In my case, attempting to auto NodaTime's Instant yields "System.Exception: Class NodaTime.Instant lacking an appropriate ctor". Since my application uses Instant liberally (it's analogous to System.DateTime or System.DateTimeOffset), creating handcrafted generators for each type is annoying.

Of the 5 options given, I feel like I only understand the dictionary approach. I'd pass a list of Generators as a new field on AutoGenConfig, then use reflection to create an internal dictionary.

@moodmosaic have your thoughts evolved on this issue?

[cmeeren]

I'd pass a list of Generators as a new field on AutoGenConfig, then use reflection to create an internal dictionary.

How does reflection enter into the picture? Are you talking about using reflection to obtain a list of the defined generators in the test library, and fill a dictionary with those?

---

@moodmosaic I don't see any important downsides to the dictionary approach. Could you elaborate, if you still hold this position? The only "downside" I can see is that the user, when using auto, has no guarantees about the contents of the config (specifically the custom generator map), and therefore isn't guaranteed that their custom configs are actually used. But I don't see how that can be guaranteed no matter which solution is used.

[moodmosaic]

I can't remember (it's been ~3 years) but it seems strange to me right now why I excluded the dictionary approach.

(I could understand that excluding the typeclass emulation sounds reasonable.)

I'd just go with the dictionary approach now.

[TysonMN]

I think this functionality would provide a workaround for hedgehogqa/fsharp-hedgehog#249.

[moodmosaic]

Yep. (Though I think we ought to provide out-of-the-box primitive generators.)

[TysonMN]

Agree. I just think it is interesting to see the connection.

[moodmosaic]

So in this case the user would pass the generator for that type through the dictionary.

[cmeeren]

I hope to have implemented this feature during the weekend. I will make a PR so you can have a look at it.

Also I think I'll wait with releasing a new version until hedgehogqa/fsharp-hedgehog#249 is fixed, so I can include changes that depend on that, too (specifically, adding support for single and decimal to the auto-generator).