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 requiringsymfony/http-kernel for theValueExporter 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 aboutformatters property inAbstractValueExporter,
• added an abstractExpandedFormatter to use expanded exports (exporting nested values).
• addedTraversableToStringFormatter extending the newExpandedFormatter.
  (this formatter is not added by default)

See the tests for basic usage.

Changelog: addedEntityToStringFormatter.

Changelog:

• eb1a34d added a priority handling for formatters.
  Using eitherAbstractValueExporter::__construct($formatter, $_...)
  orValueExporter::addFormatters(array $formatters).
• 0e066a1 madeExpandedFormatter a trait for formatters needing recursive export.
• 677c3c2 fixed an issue with the class name resolution in theInvalidFormatterException message.
• 8f63b07 added support for FQCN formatters registration instead of passing instances.
• a83684c added support for objects implementing__toString().
• ab119f0 tweaked theCallableToStringFormatter.

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:

<?phpuseApp\ValueExporter\Formatter\CustomValueToStringFormatter;useApp\ValueExporter\Formatter\OverrideValueToStringFormatter;useSymfony\Component\ValueExporter\Exporter\ValueToStringExporter;useSymfony\Component\ValueExporter\ValueExporter;ValueExporter::addFormatters(array(    CustomValueToStringFormatter::class,array(OverrideValueToStringFormatter::class,10),));// or using variadic argument of the constructorValueExporter::setExporter(newValueToStringExporter(array(CustomValueToStringFormatter::class,100),    OverrideValueToStringFormatter::class,));

Also note that priorities are handled inAbstractValueExporter 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:

<?phpuseApp\ValueExporter\Formatter\ValueToStringFormatter;useSymfony\Component\ValueExporter\ValueExporter;$value =// ...echoto_string($value);// defaultValueExporter::addFormatters(array(array(ValueToStringFormatter::class,10),));echoto_string($value);// use new formatterValueExporter::addFormatters(array(array(ValueToStringFormatter::class, -1),));echoto_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 insupports 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 withArgumentValueResolverInterface::supports andEncoder::supportsEncoding from serializer? That's why I was thinking of a parameter to test unique classes.