Since master is in features freeze, and also since I really think VarDumper has almost all the required bits, I suggest not working on this right now.

@nicolas-grekas Thank you for your feedback, I understand.

But currently, I really need it as it is proposed in that PR, to avoid requiring symfony/http-kernel for the ValueExporter only and to add it some flexibility.

Anyone can feel free to use, reuse that code for other implementation/work or when it will be the time to bring it in core.

I think I will maintain this branch for the time being. Thanks.

Little update here:

• addressed @stof comment about formatters property in AbstractValueExporter,
• added an abstract ExpandedFormatter to use expanded exports (exporting nested values).
• added TraversableToStringFormatter extending the new ExpandedFormatter.
  (this formatter is not added by default)

See the tests for basic usage.

Changelog: added EntityToStringFormatter.

Changelog:

• eb1a34d added a priority handling for formatters.
  Using either AbstractValueExporter::__construct($formatter, $_...)
  or ValueExporter::addFormatters(array $formatters).
• 0e066a1 made ExpandedFormatter a trait for formatters needing recursive export.
• 677c3c2 fixed an issue with the class name resolution in the InvalidFormatterException message.
• 8f63b07 added support for FQCN formatters registration instead of passing instances.
• a83684c added support for objects implementing __toString().
• ab119f0 tweaked the CallableToStringFormatter.

How-to

So now to register formatters, you can pass either an FQCN or an array with an FQCN and a priority as you would do for listener method:

<?php

use App\ValueExporter\Formatter\CustomValueToStringFormatter;
use App\ValueExporter\Formatter\OverrideValueToStringFormatter;
use Symfony\Component\ValueExporter\Exporter\ValueToStringExporter;
use Symfony\Component\ValueExporter\ValueExporter;

ValueExporter::addFormatters(array(
    CustomValueToStringFormatter::class,
    array(OverrideValueToStringFormatter::class, 10),
));

// or using variadic argument of the constructor
ValueExporter::setExporter(new ValueToStringExporter(
    array(CustomValueToStringFormatter::class, 100),
    OverrideValueToStringFormatter::class,
));

Also note that priorities are handled in AbstractValueExporter holding three private arrays:

• $formatters => array($formatterFqcn => (int) $priority, ...)
• $sortedFormatters => array($formatterInstance, ...)
• $cachedFormatters => array($formatterFqcn => $formatterInstance, ...)

It means that you can change the priority of a formatter in runtime:

<?php

use App\ValueExporter\Formatter\ValueToStringFormatter;
use Symfony\Component\ValueExporter\ValueExporter;

$value = // ...

echo to_string($value); // default

ValueExporter::addFormatters(array(
    array(ValueToStringFormatter::class, 10),
));

echo to_string($value); // use new formatter

ValueExporter::addFormatters(array(
    array(ValueToStringFormatter::class, -1),
));

echo to_string($value); // use formatter with a new priority

Question

Do you think I should allow to use the same formatter class multiple times as discussed in #18482? (ping @iltar :)

I don't feel it is coherent here.

I would really appreciate any one giving it a quick review or thought, I think I just need to add some other tests for better covering the priority handling.

Besides that, I believe this pseudo-component is now flexible and stable enough, so I can start using it in my work on #18411 (ref #18403).

Thanks to anyone giving a look at this experimental PR :)

I don't think it makes sense to use the same formatter class multiple times I think. If it doesn't support it on prio 10, it won't support it on anything lower either.

@iltar thank you for your review :), however I don't really understand your last sentence:

If it doesn't support it on prio 10, it won't support it on anything lower either.

Thanks again, the style can still change, but I'd really like to stabilise the functional part for now.

Cheers

If you have something hooking in on 2 priorities, let's say 10 and 20 and on 20 it doesn't trigger anything, why would it trigger something on 10? There won't be a difference in triggering both or only 1

Ok I got you, you just argue in my way: one class -> one call to support => one way to support.

Having the same class with two instances and different configurations, returning a different result when calling support makes no sens to me.

That's why I was suggesting unique class in your PR (at least for argument value resolvers).

Also I used this implementation, because I think they may be use cases for changing a priority at runtime to help debugging a particular value. Because when you need a specific overhead in supports you may want to move it to the latest after using it.

Yeah so in this PR it makes no sense because once support is declined, it won't ever return anything else. However, in my PR the difference is that there is no supports and everything is supported.

In your case I think it's best to make them unique or add a warning/exception if added twice.

Isn't that what happens with ArgumentValueResolverInterface::supports and Encoder::supportsEncoding from serializer? That's why I was thinking of a parameter to test unique classes.