Feature implementing plan : Allow other source of data

[Yopai]

Other refactoring plan :

Use an interface for the input.

Let's your input source is an array of objects; for example entities with multiple properties :

• object properties that have __toString methods
• object properties for which __toString method is not applicable, like DateTime
• properties that can be null
• virtual properties

As your library is written, it will require (speaking knowingly ;)) a whole array_map in order, for each item :

• test for object properties
• test if __toString method if available
• test if this is a DateTimeInterface
• explicitly adds virtual properties
  It is fastidious, prone to errors, and also have drawbacks, because a null property cannot be used as a key - whereas it can certainly be used as a value. So it has to be tested to know if this null must be converted into an empty string, or into zero.
  Furthermore, for people using it with an array, accessing a non-existing array in a an array is deprecated; so, in order to avoid getting a warning or an error if some of your data have not every property.

So, my proposal :

• Use an Input Interface, with two methods :
  ** getForKey($item, $property)
  ** getForValue($item, $property)
  ** and also iterable

• Implement an ArrayInput, that will systematically return $item[$property] ?? null (that is, the behaviour of the current implementation)

• make $data of type InputInterface|array; if an array is passed in, it is converted into an ArrayInput

• use $data->getForKey($item, $key) or $data->getForValue($item, $key)

Please let me think what you think about it. Like for #3 , I will implement it through successive PRs, always compatible with existing code.