Add a Yaml class to Drupal\Component\Serialization

Sorry.

Yeah, as outlined by the ultimate goal in the issue summary, this is just about consolidation + centralization + consistency (and thus also DX).

We're using the YAML serialization format in HEAD already. This patch does not add or change any usage of YAML, it only changes how code throughout core encodes and decodes YAML internally.

Hah, note that this is the exact same patch as in the other issue: I just (1) removed the Pecl class, (2) removed the Yaml wrapper, and (3) renamed the Symfony class into Yaml. Hence the gross failure in #1 ;-) — Thus, there is not actually a conflict between the two issues/patches. :) But indeed, given recent findings, the other issue could very well turn out to not actually happen, so it was a good idea to split this out after all. :)

Are there any objections to the proposed change, or can we move forward here? :)

+++ b/core/lib/Drupal/Component/Discovery/YamlDiscovery.php
@@ -7,7 +7,7 @@
 namespace Drupal\Component\Discovery;
 
-use Symfony\Component\Yaml\Parser;
+use Drupal\Core\Serialization\Yaml;

Hm. This won't work. Two options:

1. Move YamlDiscovery into Core.
2. Do not convert YamlDiscovery to use the Yaml serialization class.
3. Move the Serialization component into Component.
   (cf. #2208609-16: Move Json utility class into Drupal\Component\Serialization)

A quick grep reveals:

$ grep -rli 'Component\\Discovery\\YamlDiscovery' core/
core/lib/Drupal/Component/Discovery/YamlDiscovery.php
core/lib/Drupal/Core/Plugin/Discovery/YamlDiscovery.php
core/lib/Drupal/Core/Routing/RouteBuilder.php
core/tests/Drupal/Tests/Component/Discovery/YamlDiscoveryTest.php
core/tests/Drupal/Tests/Core/Routing/RouteBuilderTest.php

Given what this class is doing — just checking whether a given filename exists in a given list of paths, and parsing all files found — I think we should go with (1) move the YamlDiscovery class into Drupal\Core\Discovery (or Utility).

Moved YamlDiscovery into Drupal\Core\Discovery.

Apparently, it lived in there once in the past already, since some stale/outdated phpDoc still references Drupal\Core\Discovery\YamlDiscovery.

Updated for #2203411: Convert drupal_get_library() into a service

@damiankloip: The same reasons as in #2208609-14: Move Json utility class into Drupal\Component\Serialization also apply to YamlDiscovery, because the following is literally all it does:

$parsed = array();
foreach ($paths as $provider => $path) {
  $parsed[$provider] = Yaml::decode(file_get_contents("$path/$provider.$name.yml"));
}
return $parsed;

It hard-codes a Drupal-specific concept of providers and corresponding file names that are being looked up in a given set of directories.

I don't even understand why this is a class in the first place... I was very tempted to actually move this into Drupal\Core\Utility instead of an own "Discovery" component.

In any case, there's no point to expose this as a Component to the outside world. There's no concept and also no generic use-case involved that would make it worth for anyone else on this planet. :-)

Converted new instances + preexisting ones that were missing.

@damiankloip: Sorry, but that is not true. Let's stick to the facts:

1. Transliteration: A port of MediaWiki's + other transliteration components + sources, originating from https://drupal.org/project/transliteration. This is some very heavy stuff, I'd be surprised + stunned if you're able to re-implement this on your own.
2. Gettext: Proper reader/parser + writer for Gettext (.po) files. Epic effort, took several sprints to get right.
3. PhpStorage: A secure PHP file storage backend.
4. Plugin: A plugin system for extensible frameworks.
5. Archiver: A component to manage archive files. (Alternatives exist)
6. Uuid: A utility component for using the most optimal UUID implementation that exists on a system. (Alternatives exist, but they spawned off from this implementation)

Compared to that — YamlDiscovery? — LOL. ;)

Apologies, my last comment might have come across as inappropriate. That was not my intention.

What I was trying to say is that Drupal\Component is not only meant to contain decoupled and re-usable code (not relying on Drupal), but in addition, the contained components should actually be useful for other PHP projects and developers. — Code of a complexity that can be easily written in 5 minutes by any PHP developer does not really meet the aspect of being useful (and hence it will not get re-used).

I originally split these simpler changes into separate smaller issues to facilitate reviews. At this point, the effort of the parent issue is severely blocked on these child issues.

So in case moving the code into Drupal\Component\Serialization would help to move forward here, then I'm happy to concede for the sake of making progress. (I'd have to adjust all other patches accordingly.)

Is that the only objection and point of dissent?

1. Moved Drupal\Core\Serialization into Drupal\Component\Serialization.
2. Revert "Moved YamlDiscovery into Drupal\Core\Discovery."
3. Fixed @file phpDoc of DiscoverableInterface.

Forgot to update issue summary.

Haha + issue title :)

diff context conflict

Diff context conflict.

Would be great to move forward here...

#2161591: Change default active config from file storage to DB storage needlessly converts lots of code throughout core to manually pass custom arguments to Yaml\Dumper::dump().

Updated new instances.