Context variable passed through to FromDoc and PostDoc functions

[rdw]

Throwing this idea out there for comments.

One of the use cases we have is essentially cross-referencing different databases of config objects. So we'll have an item which declares some gun mounts, and those have to be registered in a gun database (because we also have guns declared on their own, too). Or we have a player class that declares its default secondary fire, which we want to look up from a database when we load the class (arguably, we don't have to do that but we are right now, so....).

It would help with this if we had access to these databases inside the FromDoc functions (or PostDoc, but we don't actually have many of those). So one way to do this would be to pass in a Context object, and the caller of Apply or Reify could supply an object to stick on there, which FromDocs could retrieve.

[tenpn]

Love it. Always a fan of reducing singletons and making things more testable.

Would it be too much of a mess to template it? Sooo Config.Apply<List<Gun>, BulletDB>("guns", ref gunList, myBulletDB)? (assuming we could emit the params in practice) It almost certainly would penetrate too many functions to be practical?

Also I didn't even know about postdoc???

[tenpn]

(it'd be optional right?)

[rdw]

Thanks for the thoughts! Yes, I think it would have to be optional. Most of the time it would be unused.

Templating is interesting; the FromDoc function gets called through reflection so it probably wouldn't be too much modification. What would it do if types didn't match, though? It seems infeasible to detect such things at compile time so it'd probably throw an InvalidCastException.

[rdw]

Actually, I guess the worst case scenario would be reifying a heterogeneous assortment of classes, each of which expects a different context type. It'd suck to have to work around that. Maybe the right solution is to null out context arguments where the type isn't assignable, and all FromDocs have to assume that their context can be null. (and of course it can't be a value type because what is the point of that)

[rdw]

The history of DarkConfig is me saying "I won't need a value type in this use case.... wait, dang."

[tenpn]

I guess just pass objects and expect the fromdoc to cast. Sounds like way too much overhead.

…

On Fri, 31 Mar 2017 at 22:45, Ryan Williams ***@***.***> wrote: The history of DarkConfig is me saying "I won't need a value type in this use case.... wait, dang." — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAWAyOb01asVGokxesYENKnZ1ImCibI9ks5rrXQUgaJpZM4MvHqN> .