(FACT-932) Add new function, fact()

[reidmv]

This PR doesn't solve for FACT-932, but is related to it and discussion
there.

The fact() function allows dot-notation reference to facts. It is an
alternative to using $facts directly with array-indexing. Array-indexing
is often onerous to use since it doesn't align with how structured facts
are accessed elsewhere in the ecosystem and if any element in a
multi-step path doesn't exist, array indexing can cause a compilation
failure.

Example usage:

fact('os.family')

[ripienaar]

Would be nice to split this into 2 functions. One to dig like this into any hash and then use that in the fact function.

[reidmv]

@ripienaar any ideas for what to call the dig-like part? dotdig()?

[ripienaar]

I'm not a good guy to ask about naming things :P core has dig(), I am not sure at all

[reidmv]

I looked briefly at just splitting this into two functions and it looked like doing that might make it harder to keep the error messages specific to the fact-lookup use case.

It could be possible to extend the existing function with a two-argument dispatch, such that it could be called for other arbitrary arrays, but when called with only one argument it behaves as it does today.

@ripienaar is there a specific use case you're thinking of for having the function split? As you mentioned dig() exists in core and allows a form of this lookup; what's specific to this function is the dot-separated-value notation used by Facter.

Would the ability to call fact() with a hash solve the use case(s) you're thinking of? E.g.

$simple = fact('os.family')
$arbitrary = $alternative.fact('os.family')

[ripienaar]

The dot notation is just quite nice and now quite pervasive throughout so the use case is just to use it on other hashes - I wish core dig was this and I think I remember asking for that when it was made. Alas now it's just odd

Naming seems off to be able to pass a extra parameter to something called fact to them dig into another non fact thing to me

[reidmv]

@ripienaar I think I agree with you on the name. I had a good time for a minute writing up a commit to allow using alternative facts, but in the end I think it's probably best for now to keep things simple and let fact() be single-purpose for looking up facts with no potentially confusing extensions. The only use case where the name makes sense is where it's being used on the $facts hash, and I think we'd rather in that circumstance promote the raw use of fact().

$facts.fact('os.family')

Reverting in the PR for now, but leaving the commit in the history so we can still look at it conversationally if we want to.

[reidmv]

What's up with the Appveyor build failures? They don't look related to this PR at all.

[tphoney]

@reidmv i will look into the appveyor failure it smells bad to me

[binford2k]

@ripienaar for the record, as part of the conversation that @reidmv and I had prompting this PR, I wrote exactly that function and proposed it in a different PR #759

If there is value in a .value() function, then we can certainly combine them.

[npwalker]

@reidmv do we need another PR to document this new function in the README?

[reidmv]

@npwalker Doh! Yes, we do.