Support mixed target data in data_get

[JosephSilber]

This will allow data_get to go many levels deep into an object/array, supporting objects/arrays interchangeably all the way down the tree:

$object = new stdClass;
$object->framework = ['name' => 'Laravel'];
$framework = data_get($object, 'framework.name');

[anlutro]

Heya, I've written a function like this myself and have a couple of suggestions.

First of all, an object that implements ArrayAccess will return false for is_array and true for is_object, but that doesn't necessarily mean that $object->{$segment} will be set. If the object implements ArrayAccess you should do an additional check

if ($object instanceof ArrayAccess && $object->offsetExists($segment))
    return $object->offsetGet($segment);

I also think that Eloquent collection should receive special treatment - its array keys does not correspond to the models' keys, so I suggest we call find($segment) as opposed to offsetGet.

If this is merged then the form builder should definitely be changed to use this instead of array_get/object_get.

[GrahamCampbell]

Also, this will need to go to the master branch, not 4.1.

[JosephSilber]

@GrahamCampbell Why? Do you think this breaks BC? Passing a nested array or a nested object still works as expected.

@anlutro Sounds good, but that will make this function a bit unwieldy (how I wish we could do this in a proper class and just defer to it. Kinda like the way the string helpers are done). If @taylorotwell thinks we should still do it, I'll gladly add it (though I'm not sure about the model keys. Don't you think that's taking it a bit too far?).

[anlutro]

I don't, primarily because I see the use of a function like this in model form binding, where proper handling of Eloquent relationships has been requested for a long time.

[JosephSilber]

@taylorotwell what do you think about adding functionality for ArrayAccess and Collection@find?