• I like the style proposed in the issue:dump()->trace()->maxDepth(4)->values($var);. I'm just wondering ifvalues() shouldn't be nameddump() orvar() or ?

As states by @derrabus, this cannot work

I don't really like the current object API:

$options = (newVarDumperOptions())    ->trace()    ->stringLength();

it's too long to type. We should not forgot we are a indebug context. So we want to be able to get a result ASAP. that's why we have the functiondd(). As short as possible.

That's why I prefer the second bullet point of@nicolas-grekascomment:

dd($this, _trace:true, _maxDepth:4);

#48474 (comment), this cannot work

yes it can, see#48474 (comment) ;)

This is ugly :) I really don't like it. And it's too slow to type.

@ro0NL I mixed my thought :/ I was talking about:

$options = (newVarDumperOptions())    ->trace()    ->stringLength();dump($this, _options:$options);

I agree the current object API is a bit much to type. I am 👍 to find a better solution.

Should I try to implement both@GromNaN solution (dump returningmixed|VarDumperOptions) and@nicolas-grekas' one, together? I wonder if it would be a bit disturbing to have both ways available, and I don't have, yet, a strong opinion for one solution over the other.

Also, I really like the solution proposed by@ro0NL. If I may find a drawback, I'm afraid this syntax could be difficult to be "discovered" by yourself without reading the documentation.

The syntax that don't work is the one that rely on __destruct.
The last suggestion mentioned by@nicolas-grekas isdump()->trace()->maxDepth(4)->dump($var) which returns the$var as expected.

I updated the feature. The new version allows you to do both ways:

// Passing options as named parametersdump('Values', _trace:5, _flags: AbstractDumper::DUMP_STRING_LENGTH);// Use the options builder syntaxdump()    ->trace(5)    ->stringLength()    ->dd('Values')// or ->dump('Values');

Still investigating on how to useTraceStub. Otherwise, this works well! And it isso much cleaner and quicker to type.

Also, I made the choice to only have the options builder syntax ondump, notdd. I did this, because I think it is, in my opinion, a good thing to keepnever return type ondd (becausenever|VarDumpOptions is obviously a forbidden return type). Of course, passing options as named parameters todd also works!

I've been able to useTraceStub to display the backtrace. Here is the result:

When dumping large objects, it could be nice to be able to have the possibility to dump only one or several properties instead of the full object. Something like:_path: 'foo.bar' and_path: ['foo.bar', 'baz.bat'] maybe?

@nicolas-grekas thank you for the review, I'll check this out! The env var is also a great idea too, in my opinion.
Edit: the env var mechanism is in!

@dunglas I really like your proposition! Giving the size of this PR, I think it would deserve a separate one. Definitely keeping your idea this in mind 👍

Hey@alexandre-daubois! We're currently working onBuggregator, and it can be used as a server for displaying dumps for the var-dumper component. I really like your PR with options. However, it would be great if you also provided the ability to add custom context as an array to adump function.

$options = (newVarDumperOptions())    ->withContext(['language' =>'php']);dump($this, _options:$options);

This feature can be used in various scenarios, such as providing information about syntaxhighlighting for string dumps or offering details about the project to which a dump should be linked.

Would you kindly consider adding support for custom context in thedump function

Thanks for PR!

Hey@butschster! Thank you for your interest in this PR! I kinda forgot about it, but I still think it is worth it to have this in the framework.

About the context feature you're talking about: while I understand it would help in your case, I find it weird to add some context here that won't be used apart from super precise use cases. Two solutions here:

• If you have some strong reasons and use case, a complementary PR could be proposed ;
• We may keepVarDumpOptionsnot final so you can extend it for all your needs. I think that's the quick win 😊

Anyway, I'll try finalize this PR. Thanks for digging it up!

I pushed a rebased, cleaner version. I removed the Options class and replaced it with an array, which seems enough. Tests are fixed.

We have an unresolved concern, which is that dump-handlers don't have to react to options, and we don't have an internal API to communicate those options to them. If we do want options, we need that API.

I wasn't exactly sure what you meant here. I updatedVarDumper::dump() in order to pass options to the registered dump handler. This way, if one defines its own handler, options can either be handled or ignored. Is that what you had in mind?

PR title and header needs to be updated to reflect the content of this PR, thanks

Should be better now@OskarStark