rfc:readline_interactive_shell_result_function_straw_poll

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:readline_interactive_shell_result_function_straw_poll [2021/01/06 03:23] – tandrerfc:readline_interactive_shell_result_function_straw_poll [2021/01/16 20:25] (current) – tandre
Line 1: Line 1:
 ====== Straw poll: Interest in configurable callback to dump results of expressions in ''php -a'' ====== ====== Straw poll: Interest in configurable callback to dump results of expressions in ''php -a'' ======
-  * Version: 0.1+  * Version: 0.2
   * Date: 2021-01-05   * Date: 2021-01-05
   * Author: Tyson Andre, <tandre@php.net>   * Author: Tyson Andre, <tandre@php.net>
-  * Status: Draft+  * Status: Closed
   * First Published at: https://wiki.php.net/rfc/readline_interactive_shell_result_function_straw_poll   * First Published at: https://wiki.php.net/rfc/readline_interactive_shell_result_function_straw_poll
  
Line 137: Line 137:
 A couple of notes on this: A couple of notes on this:
  
-  * The readline-based shell for "php -a" was added in PHP 5.1 +  * The readline-based shell for ''php -a'' was added in PHP 5.1    [https://www.php.net/manual/en/features.commandline.interactive.php] and ''<nowiki>__debugInfo</nowiki>'' not until 5.6 [https://wiki.php.net/rfc/debug-info] 
-    [https://www.php.net/manual/en/features.commandline.interactive.php] and +  * I agree that the existing debug outputs are quite verbose, but I don't think that's a problem unique to the REPL. ''var_export()'' is constrained to render valid PHP code, but ''print_r()'' and ''var_dump()'' could and perhaps should represent objects more compactly. 
-    __debugInfo not until 5.6 [https://wiki.php.net/rfc/debug-info] +  * That compact representation of a Point (''Point(x: 1, y: 2)'') would be useful pretty much everywhere anyone wanted debug output. It would also be possible to build it on top of the existing functionality (key-value pairs from ''<nowiki>__debugInfo</nowiki>'' if defined, else all properties). 
-  * I agree that the existing debug outputs are quite verbose, but I don't +  * Allowing objects to overload the output seems much preferable to the formatting function having to know all the special cases, so I'm not convinced of the need to hook the entire output for the shell. 
-    think that's a problem unique to the REPL. '' var_export()'' is constrained +  * I can't find any references off-hand, but I'm pretty sure popular REPLs in other languages take that approach: use existing 
-    to render valid PHP code, but ''print_r()'' and ''var_dump()'' could and perhaps +    pretty-printing mechanisms from the language, which in turn can be overloaded by individual types / classes.
-    should represent objects more compactly. +
-  * That compact representation of a Point (''Point(x: 1, y: 2)'') would be useful pretty much +
-    everywhere anyone wanted debug output. It would also be possible to +
-    build it on top of the existing functionality (key-value pairs from +
-    ''__debugInfo'' if defined, else all properties). +
-  * Allowing objects to overload the output seems much preferable to the +
-    formatting function having to know all the special cases, so I'm not +
-    convinced of the need to hook the entire output for the shell. +
-  * I can't find any references off-hand, but I'm pretty sure popular +
-    REPLs in other languages take that approach: use existing +
-    pretty-printing mechanisms from the language, which in turn can be +
-    overloaded by individual types / classes.+
 </blockquote> </blockquote>
  
 Adding a pretty-printing alternative to ''var_dump'' would be a separate RFC proposal but may be worth proposing. Adding a pretty-printing alternative to ''var_dump'' would be a separate RFC proposal but may be worth proposing.
-( e.g. ''public function debugRepresentation(): string'' )+( e.g. ''public function <nowiki>__debugRepresentation()</nowiki>: string'' )
  
 ==== Exposing the ability to handle input and recover from fatal errors in interactive shells ==== ==== Exposing the ability to handle input and recover from fatal errors in interactive shells ====
Line 208: Line 196:
  
 ===== Vote ===== ===== Vote =====
 +
 +Voting started on 2021-01-07 and ends 2021-01-14
  
 **This is a multiple choice poll,** fill out any acceptable options. **This is a multiple choice poll,** fill out any acceptable options.
Line 220: Line 210:
 </doodle> </doodle>
  
-What tools do you currently use?+==== What tools do you currently use? ==== 
 + 
 +**Clicking vote will only submit an answer for the question(form) that you voted on. To answer both questions, you must click vote for one question, choose the answer for the other question, then vote for the other question.**
  
 <doodle title="Straw poll: Preferred shell choice/substitute before this RFC was created" auth="tandre" voteType="multi" closed="true"> <doodle title="Straw poll: Preferred shell choice/substitute before this RFC was created" auth="tandre" voteType="multi" closed="true">
Line 238: Line 230:
   * https://wiki.php.net/rfc/readline_interactive_shell_result_function   * https://wiki.php.net/rfc/readline_interactive_shell_result_function
   * https://externals.io/message/111073 "Improving the usability of PHP's interactive shell? (completions, displaying expression results, custom syntax)"   * https://externals.io/message/111073 "Improving the usability of PHP's interactive shell? (completions, displaying expression results, custom syntax)"
 +
 +===== Changelog =====
 +
 +0.2 Visually separate the forms
rfc/readline_interactive_shell_result_function_straw_poll.1609903383.txt.gz · Last modified: 2021/01/06 03:23 by tandre

Page Tools