I ' m betting uAiiiiiiLmao means something more like flush output as it gets generated . Indeed . For that you can call $ responsesetContent $ myInvokable , where $ myInvokable is a closure , or an object with invoke defined . Therein , you can generate your output piecemeal and echo each piece or write it to STDOUT , or whatever else you like . If I just echo it and it ' s not buffered by the caller or send it to STDOUT it ' d be unfortunate leak of abstraction , because the purpose of this extension is supposedly to get away from globals . Well the default context of echo , STDOUT , and writing to STDOUT via other means is a part of the global nature of a response , it ' s not different than dealing with $ GET , $ POST and so on . Ideally any wrapper around the global requestresponse mechanics would provide a thin encapsulation layer which allows one not just to supply input from alternative sources , but also direct output to alternative sources . Otherwise all that ' s left is the fancy syntax change . And it ' s not much of a win , to be honest . I have a similar minimal wrapper around RequestReader and ResponseWriter , much like your two object , in userland . The sole purpose I did it is so I can run my PHP in alternative setups , say , a persistent process with a server , or a persistent process communicating with a server over named pipes FastCGI style . In this context the invokable would preferably work similar to a simple iterator or as an iterator , where each time it ' s invoked it returns a string , part of the output , and when it ' s done , it returns null . Where that string goes can then be decided by the caller . Using echo might work , if it ' s explicitly documented the output might be captured and redirected , and that direct writing to STDOUT via fwrite etc . is not allowed .