What would be the resulting PHP structure ?

Nothing's finished but I began this.
I made a class per tag and it resulted to:

Yaml/
    Tag/
        - BinaryTag
        - BoolTag
        - FloatTag
        - IntTag
        - NonSpecificTag
        - NullTag
        - StrTag
        - TimestampTag

Would it be possible to have a much smaller diff, to only add code for supporting first level tags, !foo?
About the resulting output PHP structure, should we add a single TaggedValue class with getTag and getValue?
Would that make sense ?

The idea looks interesting and might help implementing #21071. I am just not sure how we should best implement it to allow some flexibility which will probably be needed.

Note that #21071 is ready and shouldn't be waiting for this one. But of course, it'd be great to leverage tags and use them instead of special keys when it's ready.

Would it be possible to have a much smaller diff, to only add code for supporting first level tags, !foo?

@nicolas-grekas and hardcode in the parser the defaults ?

About the resulting output PHP structure, should we add a single TaggedValue class with getTag and getValue?
Would that make sense ?

I don't think that's worth it, having it as arguments is enough imo.

The idea looks interesting and might help implementing #21071. I am just not sure how we should best implement it to allow some flexibility which will probably be needed.

@xabbuh indeed, you can still take a look at other libraries and see if their implementation inspires you (js-yaml, the php yaml extension, pyyaml, etc.).

Note that my current implementation doesn't support dynamic tags name, I don't think this is useful, so !php/object:foo would have to be deprecated in favor of !php/object foo

@nicolas-grekas I agree that it shouldn't wait. But having sort for custom tags in 3.3 would allow to update your implementation before the final release.

hardcode in the parser the defaults

Of course not, "foo" === "whatever" !== "hardcoded".

having it as arguments is enough imo

What does that mean? Looks like we're talking foreign languages :)

So, back to my first question, which still needs an answer: "What would be the resulting PHP structure ?", where "resulting" means "output from the parser" (and not "internal structure").

Let's take an example, in the context of the DI component:
$output = Yaml::parse('- !iterator [...]').
What should be $output?

My personal pov is that it could be well enough to just make it be:
array( new TaggedValue('iterator', [...]) )

so that eg the DI Yaml loader could then iterate over this structure and do at some point:

if ($value instanceof TaggedValue) {
    if ('iterator' === $value->getTag()) {
        $iteratedValues = $value->getValue();
        // etc. (like validation)
        $resultingValue = new IteratorArgument(...);
    }
}

there is another possibility which could be to make Yaml able to hydrate an IteratorArgument directly, so that $output could directly be array( new IteratorArgument(...) ).
But that looks way too much complexity to add to me.

hardcode in the parser the defaults

Of course not, "foo" === "whatever" !== "hardcoded".

@nicolas-grekas did you mean having this kind of diff?

having it as arguments is enough imo

What does that mean? Looks like we're talking foreign languages :)

I was talking about having an interface for tags (and manage them in the parser):

interface TagInterface
{
    /**
     * @param string $value a plain scalar
     *
     * @return mixed
     */
    public function construct($value);
}

But it seems you were talking about having a special class for the output 😛

So, back to my first question, which still needs an answer: "What would be the resulting PHP structure ?", where "resulting" means "output from the parser" (and not "internal structure").

 Yaml::parse('- !iterator [...]') === array( new TaggedValue('iterator', [...]) );

It seems weird to me; core tags (eg !!binary, !!str, etc.) would be directly transformed in the parser but not custom tags?
That would also force people using custom tags to iterate over the entire output to find these tags.
One last argument, it would be a bc break for scalars (!iterator foo currently returns "!iterator foo").

I think it is much more powerful to pass this responsibility to the parser, you tell it to convert !iterator to IteratorArgument and that's all. It took me ~170 lines of code to support it.

About the diff, yes!

core tags would be directly transformed in the parser but not custom tags

custom vs core, that's enough a difference to me, so yes

force people using custom tags to iterate over the entire output to find these tags

sure, but people are already iterating over the resulting structure to just read what's inside of it, so that doesn't shock me.

more powerful to pass this responsibility to the parser

responsibility = complexity. Given that we don't want to build a full hydrating system here, we can only support simple types here (similar to doctrine annotations). Which means "more powerful": maybe, but powerful enough: not sure.

Thus, my personal preference is simplicity here. But that doesn't prevent you from trying your way :)