dflydev / dflydev-dot-access-data Goto Github PK

Is there a way to get a list of all dotted notation keys and their respective values?

Ie, from your demo array:

hosts.hewey.username = 'hman'
hosts.hewey.password = 'HPASS'
...
hosts.lewey.roles = ['db']

In order to avoid constant null-checking I would like the ability for this library to throw exceptions when trying to access something that does not exist. Specifically, I would like to change these behaviors:

// Fetching a non-existent key with no default given
$data->get('foo.bar'); // returns null

// Fetching a non-existent key with `null` set as the default
$data->get('foo.bar', null); // returns null

// Fetching a non-existent key with a non-`null` default
$data->get('foo.bar', 42); // returns 42

To this:

// Fetching a non-existent key with no default given
$data->get('foo.bar'); // CHANGE: would throw an exception instead of returning null

// Fetching a non-existent key with `null` set as the default
$data->get('foo.bar', null); // returns null

// Fetching a non-existent key with a non-`null` default
$data->get('foo.bar', 42); // returns 42

Obviously this will be a BC break and therefore require a bump in the major version. Anyone wanting the old functionality could set null as the second argument.

ArrayAccess

One outstanding question is what the behavior of offsetGet() should be - calling this indirectly like $data['foo.bar'] does not provide the ability to define a default value. I have no preference on whether this should return null or throw an exception.

Any chance this is on your radar? It may sound obscure if this was only ever to be intended as a dot notation interface to YAML files, but in the case of some PHP applications when dealing with their insane structured arrays - I think something like dot notation would be a nice utility.

Just a thought. :)

The README.md file says that the license is New BSD, but the GitHub says the license is MIT.
What is the right license?

Data::import(), Data::importData(), and Util::mergeAssocArray() support this notion of "clobbering" when trying to merge in two arrays. In a nutshell:

For example:

$a = ['x' => 'a', 'foo' => ['foo'], 'a' => true];
$b = ['x' => 'b', 'foo' => ['bar'], 'b' => true];

Util::mergeAssocArray($a, $b, false);
// ['x' => 'a', 'foo' => ['foo'], 'a' => true, 'b' => true]

Util::mergeAssocArray($a, $b, true);
// ['x' => 'b', 'foo' => ['bar'], 'a' => true, 'b' => true]

However, there's no ability to merge non-associative array values. In the example above, it's impossible for me to have the foo key contain ['foo', 'bar').

To give a more realistic example, I might have Data elements representing HTML tag attributes:

$attributes = [
    'id' => 'logo',
    'class' => ['img-responsive'],
    'alt' => 'My logo',
];

And I want to merge in some additional attributes:

$more = [
    'class' => ['box-shadow'],
    'alt' => 'Our Awesome Logo',
];

In order to get this output:

[
    'id' => 'logo',
    'class' => ['img-responsive', 'box-shadow'],
    'alt' => 'Our Awesome Logo',
];

Unfortunately neither $clobber mode allows this.

Proposal

Add a third mode which acts more like PHP's array_merge() function - it will clobber things with string keys but append things with numeric keys.

To do this, we'll create three constants, one for each mode:

public const PRESERVE = 0; // equivalent to `false` in 1.x
public const REPLACE = 1; // equivalent to `true` in 1.x; default value
public const MERGE = 2; // the new approach I'm proposing

We'd also rename $clobber to $mode since it's no longer all-or-nothing.

This approach provides some level of backward-compatibility for anyone not using strict types, as false gets coerced to 0 and true gets coerced to 1.

Hi, Im using composer and drush to manage a Drupal project. When I run drush commands, I got this message :
PHP Fatal error: Uncaught Error: Class 'Dflydev\DotAccessData\Data' not found in C:\xampp\htdocs\refonte\vendor\consolidation\config\src\Config.php:35 Stack trace: #0 C:\xampp\htdocs\refonte\vendor\consolidation\config\src\Util\ConfigOverlay.php(31): Consolidation\Config\Config->__construct() #1 C:\xampp\htdocs\refonte\vendor\drush\drush\src\Config\ConfigLocator.php(101): Consolidation\Config\Util\ConfigOverlay->__construct() #2 C:\xampp\htdocs\refonte\vendor\drush\drush\src\Preflight\Preflight.php(68): Drush\Config\ConfigLocator->__construct('DRUSH_', '11') #3 C:\xampp\htdocs\refonte\vendor\drush\drush\drush.php(68): Drush\Preflight\Preflight->__construct(Object(Drush\Config\Environment)) #4 C:\xampp\htdocs\refonte\vendor\drush\drush\drush(3): require('C:\\xampp\\htdocs...') #5 C:\xampp\htdocs\refonte\vendor\bin\drush(112): include('C:\\xampp\\htdocs...') #6 {main} thrown in C:\xampp\htdocs\refonte\vendor\consolidation\config\src\Config.php on line 35
What am I missing ?

I'd like to use this library in the next major release of league/commonmark. Unfortunately I'm blocked by the fact that v1 of my library uses array paths with slashes (foo/bar) instead of dots (foo.bar) and I'd like to preserve that for backward-compatibility reasons.

I'd therefore like to propose the ability for the library to allow for both . and / as key path delimiters.

I have working code I'd be happy to contribute, but it would rely on #18 (merged) and #20 to be merged first to avoid merge conflicts.

Hi,
Is it possible to use wildcards?
Sth. like this: "array.value.*.array.value"

Thank you

Hi,

Would you consider releasing a new major with support for only PHP7?

If yes, I'll be happy to contribute.

It looks like master has some commits that haven't made it into a release (adding the has method).

It'd be great if that could be released as a v1.1.0 release 👼