Download the PHP package cyber-duck/fluent-debug without Composer
On this page you can find all versions of the php package cyber-duck/fluent-debug. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package fluent-debug
🚨 Discontinued 🚨
This package will no longer be supported.
Fluent / Chaining Methods/ Functions xDebug Library
Why?
Frameworks like Laravel make heavy usage of, and encourage, method chaining
Consider code like the following random line taken from Laravel framework:
That looks lovely. But there's a problem. Suppose I'm interested in the return value of
and I wish to examine this in a debugger.
At present, the only way I'm aware of doing this in PHP1 with xDebug is either to step through it, or to tediously rewrite the code to introduce intermediate variables, i.e. rewrite the above to
which doesn't sound particularly difficult in this example but soon becomes a massive mess.
Let's consider another random line:
Suppose I'm interested in the return value of $sausage->bacon() here. Where do I stick a breakpoint to get that?
If I put it on the line, I have to step through the call to bacon and intercept the return value, which is sometimes rather difficult.
Or perhaps I can put the breakpoint on the first line of the call to meatProcess. A third option is to do something
like
And put a breakpoint on the second line. But suppose the call to ketchup has altered $a? You're going to be misled!
And in any case, I'm messing up the code again.
This kind of thing is why some programmers are against method chaining in general - the debugging really is made much harder.
See for example https://ocramius.github.io/blog/fluent-interfaces-are-evil/
But we live in the real world and it's a popular way of doing things, and done well as with Laravel it makes your code so much simpler to read.
How?
So here I present a very simple extension that I believe takes out the vast majority of the debugging pain caused by fluent method chaining.
The extension is in two parts. Firstly, there is a trait with two methods. debugBreak and debugBreakIf. These are
essentially wrappers around the xdebug_break function installed with xdebug.
Usage is like:
or perhaps:
or indeed:
To use this, add use CyberDuck\Traits\DebugsFluently to any class where you wish to use it (or possibly its parent).
On my ever increasing todo list is a plan to write something that will add this to every class for you automatically.
Secondly - primarily intended for usage in function chaining - are the global functions debugBreak and debugBreakIf.
The above example would become
Or there is debugBreakIf - The second argument works in the same way as the debugBreakIf method in the trait.
Footnotes
1: There is a way in .NET - see https://davefancher.com/2016/01/28/functional-c-debugging-method-chains/
