print with newline

php.internals

Steven Penny

7 years ago
with PHP, several methods are available to produce output: echo "hello world\n"; print "hello world\n"; print_r("hello world\n"); var_export("hello world\n"); However all these methods have something in common: they do not produce their own newline. With each method, the user is required to provide a newline with "\n", PHP_EOL or similar. This is bothersome because many other programming languages offer such a method. For example Python: print('hello world') Perl: use feature say; say 'hello world'; Ruby: puts 'hello world' Lua: print 'hello world' Even C: #include <stdio.h> int main() { puts("hello world"); } Out of the above examples, I would say Perl and Ruby are most similar to PHP, in that they also have the "print" method: $ perl -e 'print 2; print 3;' 23 $ ruby -e 'print 2; print 3;' 23 However even in this case, "print" can be made to produce a newline by default: $ perl -e '$\ = "\n"; print 2; print 3;' 2 3 $ ruby -e '$\ = "\n"; print 2; print 3;' 2 3 My request would be one of the following: 1. Modify one or more of "print", "print_r", "var_export" such that they produce a newline by default 2. Modify one or more of "print", "print_r", "var_export" such that they have an argument similar to Python "end" that controls what follows the input, if anything: https://docs.python.org/library/functions.html#print 3. Add a new method, perhaps "echoln", "println", "say" or similar, that outputs a newline by default 4. introduce a new variable, perhaps "$OUTPUT_RECORD_SEPARATOR", "$ORS", "$\" or similar, that controls output record separator I understand that some of these methods are old and unlikely to change, but if I do nothing then I have only myself to blame.

Johannes Schlueter

7 years ago
On Sa, 2019-03-02 at 11:59 -0800, Steven Penny wrote:
> 1. Modify one or more of "print", "print_r", "var_export" such that > they produce >    a newline by default
This is a break of backwards compatibility in a bad way. This breaks people doing specific output.
> 2. Modify one or more of "print", "print_r", "var_export" such that > they have an >    argument similar to Python "end" that controls what follows the > input, if >    anything: > >    https://docs.python.org/library/functions.html#print
PHP's echo has the option already:   echo $foo, PHP_EOL; not much difference i effort to writing    print $foo, true; except that the code is explicit.
> 3. Add a new method, perhaps "echoln", "println", "say" or similar, > that outputs >    a newline by default
function println($a) {     echo $a, PHP_EOL; } Can easily be done in library.
> 4. introduce a new variable, perhaps "$OUTPUT_RECORD_SEPARATOR", > "$ORS", "$\" or >    similar, that controls output record separator
Such magic is hard to debug and easily leads to bugs in user code. While sometimes having a shortcut at hand is nice, next request will be to automatically add a "<br>" as we often produce HTML and thn the ex request and next and this becomes messy and making everything harder for very little benefit. johannes

Steven Penny

7 years ago
On Sat, 02 Mar 2019 22:15:49, johannes schlueters wrote:
> PHP's echo has the option already: > > echo $foo, PHP_EOL; > > not much difference i effort to writing > > print $foo, true; > > except that the code is explicit.
my request was not "how to print a newline with PHP". the request is for PHP to implement a builtin method that prints a newline *by default*. currently no method exists that i know of.
> function println($a) { > echo $a, PHP_EOL; > } > > Can easily be done in library.
again not a builtin.
>> 4. introduce a new variable, perhaps "$OUTPUT_RECORD_SEPARATOR", "$ORS", "$\" >> or similar, that controls output record separator > > Such magic is hard to debug and easily leads to bugs in user code.
you post this without recognizing that Perl and Ruby already have this for many years.
> While sometimes having a shortcut at hand is nice, next request will be > to automatically add a "<br>" as we often produce HTML and thn the ex > request and next and this becomes messy and making everything harder > for very little benefit.
at least 5 other popular programming languages implement this already, and have for many years. its even part of the POSIX standard: http://pubs.opengroup.org/onlinepubs/9699919799/functions/puts.html so at a minimum it should be implemented as part of PHP POSIX: http://php.net/ref.posix

Rowan Collins

7 years ago
On 02/03/2019 23:15, Steven Penny wrote:
>>> 4. introduce a new variable, perhaps "$OUTPUT_RECORD_SEPARATOR", >>> "$ORS", "$\" >>> or similar, that controls output record separator >> >> Such magic is hard to debug and easily leads to bugs in user code. > > you post this without recognizing that Perl and Ruby already have this > for many > years.
I think Johannes recognises that, but considers it a poor design choice on the part of those languages. Perl has a reputation as a rather cryptic, "write only" language, best suited to short, throw-away scripts, and cryptically named magic variables like this are a big part of that. Regards,
-- Rowan Collins [IMSoP]

Johannes Schlueter

7 years ago
On So, 2019-03-03 at 14:33 +0000, Rowan Collins wrote:
> On 02/03/2019 23:15, Steven Penny wrote: > > > > > > > > > > > > > 4. introduce a new variable, perhaps > > > > "$OUTPUT_RECORD_SEPARATOR",  > > > > "$ORS", "$\" > > > > or similar, that controls output record separator > > > Such magic is hard to debug and easily leads to bugs in user > > > code. > > you post this without recognizing that Perl and Ruby already have > > this  > > for many > > years.  > > I think Johannes recognises that, but considers it a poor design > choice  > on the part of those languages.
In the context of those languages it might be an acceptable or even good choice. In context of PHP it means that each function, which prints anything to the output stream eventually has to set or check that value as another library might have set the flag in the "wrong" way. Other languages might have a "per module" scope or something where this could be set for a module, unaffected from other modules. PHP doesn't. johannes

Sara Golemon

7 years ago
On Sat, Mar 2, 2019 at 1:59 PM Steven Penny <svnpenn@gmail.com> wrote:
> with PHP, several methods are available to produce output: > [[::snip::]]
<?php function println(string $x): void { echo $x, PHP_EOL; } I hereby grant a public domain license to the above code and wish you godspeed bundling it into a composer package to be enjoyed by users of every active version of PHP. -Sara

Steven Penny

7 years ago
On Sun, 03 Mar 2019 03:36:50, Sara Golemon wrote:
> function println(string $x): void { > echo $x, PHP_EOL; > } > > I hereby grant a public domain license to the above code and wish you > godspeed bundling it into a composer package to be enjoyed by users of > every active version of PHP.
my request was not "how to print a newline with PHP". the request is for PHP to implement a builtin method that prints a newline *by default*. currently no method exists that i know of.

Legale Legage

7 years ago
You trеw the bait with no luck. If you didn't get the hint. Your request have extremely low probability of acceptance. Try something else. On Sun, Mar 3, 2019, 05:26 Steven Penny <svnpenn@gmail.com> wrote:

Steven Penny

7 years ago
On Sun, 03 Mar 2019 04:47:10, Legale Legage wrote:
> You trеw the bait with no luck. If you didn't get the hint. Your request have > extremely low probability of acceptance. Try something else.
how about you dont tell me what to try, and i dont tell you how to spell "took". deal?

Ryan Jentzsch

7 years ago
I've always wondered why PHP didn't have a built in command or function that behaved as `echo` but with a EOL. I propose not to modify `print` or `echo` (as this was rightly pointed out to cause b/c). How difficult would it be to add a new statement and/or function to the PHP core called `say` / `say()` that has an EOL? This seems to me to be simple to do. The benefit is less code to type in user land (ex: `say 'Hello World';` as opposed to `echo 'Hello World' . PHP_EOL;`

Joe Watkins

7 years ago
Sara, where do I send pull requests? <?php function println(string $format, ...$args) : void { \vprintf($format . \PHP_EOL, $args); } function fprintln($stream, string $format, ...$args) : void { if (!\is_resource($stream)) { throw new \TypeError(\sprintf( "Argument 1 passed to %s expected to be a resource, %s given", __FUNCTION__, \is_object($stream) ? \sprintf( "instance of %s", \get_class($stream) ) : \gettype($stream))); } \vfprintf($stream, $format . \PHP_EOL, $args); } function sprintln(string $format, ...$args) : string { return \vsprintf($format . \PHP_EOL, $args); } Jokes aside, this is so trivially achievable in userland that there is no justification whatever for an internal function or functions, or constructs, or opcodes. Cheers Joe On Sun, 3 Mar 2019 at 06:50, Ryan Jentzsch <ryan.jentzsch@gmail.com> wrote:

Alexandru Pătrănescu

7 years ago
Steven, Ryan, Adding new functions is also considered BC break because users might have those functions in their code. Over the years new functions were added to PHP core but mostly there were functions that saved in the userland code more than one line of code. Like array_first_key was accepted but array_first_value didn't. And would you all stop with PHP_EOL? If my code will ever run on something different than Linux, I want it to be portable, not generate files differently. I think we should define PHP_EOL_N constant so people will use it more... Jokes aside, each case might need a different version of they println/say implementation. Maintaining it in core is probably not worth the effort as it could be more easily maintained in userland. You can use https://packagist.org/packages/print/ln in the meantime. Or publish you own and use it. Regards, Alex On Sun, Mar 3, 2019, 08:49 Joe Watkins <krakjoe@gmail.com> wrote:

Ryan Jentzsch

7 years ago
Thanks for the explanation of b/c. I didn't know PHP is this rigid. Now I do... On Sun, Mar 3, 2019 at 1:30 AM Alexandru Pătrănescu <drealecs@gmail.com> wrote:

Steven Penny

7 years ago
On Sun, 03 Mar 2019 06:49:25, Joe Watkins wrote:
> Jokes aside, this is so trivially achievable in userland that there is no > justification whatever for an internal function or functions, or > constructs, or opcodes.
if thats the case we better go ahead and remove these in favor of "base_convert": - bindec - decbin - dechex - decoct - hexdec - octdec as they are so trivially achievable in userland that there is no justification whatever for an internal function or functions, or constructs, or opcodes.

Johannes Schlueter

7 years ago
On So, 2019-03-03 at 05:53 -0800, Steven Penny wrote:
> On Sun, 03 Mar 2019 06:49:25, Joe Watkins wrote: > > > > Jokes aside, this is so trivially achievable in userland that there > > is no > > justification whatever for an internal function or functions, or > > constructs, or opcodes. > if thats the case we better go ahead and remove these in favor of > "base_convert": > > - bindec > - decbin > - dechex > - decoct > - hexdec > - octdec > > as they are so trivially achievable in userland that there is no > justification > whatever for an internal function or functions, or constructs, or > opcodes.
There is a difference between adding and removing features. Also there is development and learnings from the past. In the past we added more or less any function. Over time this lead to different issues (like breaking user code, always having request for new variants, inconsistencies, ...) so we got more restrictive over time. Also PHP got faster, which allows more functions without notable overhead to be written in PHP instead of part of the implementation. This has the benefit that more people can write and maintain those, as well debugging is simpler. Also the environment improved. Things like composer and packagist as well as improved autoloading allow simpler distribution and usage of userspace libraries. Sometimes we might add some small helper routines, but that's a cost/benefit analysis and since the "auto new line" hasn't been requested often (I can't remember any such request from last 15+ years, doesn't man there was, but certainly not recurring) this doesn't seem to be a thing PHP users miss a lot. johannes

Lester Caine

7 years ago
On 03/03/2019 05:34, Steven Penny wrote:
>> You trеw the bait with no luck. If you didn't get the hint. Your >> request have >> extremely low probability of acceptance. Try something else. > > how about you dont tell me what to try, and i dont tell you how to spell > "took".
Threw is the more likely correction ... The fact that you think adding a line feed by default will solve something tells me you have not looked at the problem properly. Same as the developers on many projects where we seem to get extra unnecessary blank lines probably because the language throws on in by default. When the browser displays HTML one needs a <br/> for a new line rather than extra white space, so since PHP essentially targets web page generation a 'default' new line needs to be properly considered as to just how to actually create it on the output. I get pigged off by paypal throwing in EXTRA blank lines in the address data which have to be stripped before you can use it following a paste ... adding hard page ends needs to be properly thought about!
-- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

Sara Golemon

7 years ago
On Sat, Mar 2, 2019 at 10:26 PM Steven Penny <svnpenn@gmail.com> wrote:
> On Sun, 03 Mar 2019 03:36:50, Sara Golemon wrote: > > function println(string $x): void { > > echo $x, PHP_EOL; > > } > > > > I hereby grant a public domain license to the above code and wish you > > godspeed bundling it into a composer package to be enjoyed by users of > > every active version of PHP. > > my request was not "how to print a newline with PHP". the request is for > PHP to > implement a builtin method that prints a newline *by default*. currently no > method exists that i know of. > > My apologies, I was obviously not being clear.
What I should have said is that your request is bad and you should feel bad. Hope that clears things up! -Sara

Steven Penny

7 years ago
On Mon, 04 Mar 2019 00:19:32, Sara Golemon wrote:
> My apologies, I was obviously not being clear. > What I should have said is that your request is bad and you should feel bad. > > Hope that clears things up!
My apologies, I was obviously not being clear. What I should have said is fuck yourself. Hope that clears things up!

Stas Malyshev

7 years ago
Hi!
> My apologies, I was obviously not being clear. What I should have said is > fuck yourself.
Please avoid such language on the list. This is not Twitter and not any other forum where such things are welcome. If you can't keep yourself within the bounds of civilized discussion, you probably should consider using some other forum or delay your responses until you are sufficiently in control to avoid such behavior. The correct behavior from now on would be to a) apologize and b) never use such language on the list again. Thanks,
-- Stas Malyshev smalyshev@gmail.com

Steven Penny

7 years ago
On Mon, 04 Mar 2019 00:44:59, Stanislav Malyshev wrote:
> Please avoid such language on the list. This is not Twitter and not any > other forum where such things are welcome. If you can't keep yourself > within the bounds of civilized discussion, you probably should consider > using some other forum or delay your responses until you are > sufficiently in control to avoid such behavior. The correct behavior > from now on would be to a) apologize and b) never use such language on > the list again.
No, wrong. This is Twitter. I made a reasonable proposal with possible solutions, examples and references: https://marc.info?m=155155677129898 and what did i get? 4 joke/rude replies, some from PHP developers: - https://marc.info?m=155158424003446 - https://marc.info?m=155158846204229 - https://marc.info?m=155159579405704 - https://marc.info?m=155165880221224 and then i get this private email, which i think holds quite well for my point:
> It is uselses to discuss anything with PHP core devs. They live in their own > little world that has no reality in real language development. Above argument > will be ignored, because they know it's a valid argument. They only react to > statements that have a slight error (or they think they have a point) to take > you or your statement apart. > > Why do you think there are other, more recent (and even older), languages > which are way more consistent and thought out? > > They also have the tendency to react hostile to any argument that does not > match their ideas. This is one of the reasons why I don't contribute to PHP, > even though I would have liked to code internals and php-fpm.
i was considering writing an RFC per this message: https://marc.info?m=155162451812440 but after the rude and joke responses i wont waste my time. you dont want people treating this like twitter, then maybe look at your own people first.

Stas Malyshev

7 years ago
Hi!
> No, wrong. This is Twitter. > > I made a reasonable proposal with possible solutions, examples and > references:
It does not matter what you did before. It's not a "who spit on whom first" discussion in a kindergarten. It's "you don't use this kind of language here, period" discussion on this list. If you can't abide by that, please use some other list. That's it. Thanks,
-- Stas Malyshev smalyshev@gmail.com

Steven Penny

7 years ago
On Mon, 04 Mar 2019 01:58:35, Stanislav Malyshev wrote:
> It does not matter what you did before. It's not a "who spit on whom > first" discussion in a kindergarten. It's "you don't use this kind of > language here, period" discussion on this list. If you can't abide by > that, please use some other list. That's it.
again, wrong. this list *is* kindergarten, as even PHP devs treat it that way, as ive demonstrated. if you wish to disregard the evidence i provided of that, its your business. same as if you decide to ban me. i would rather you not, but frankly at this point it doesnt seem like a loss. cheers

Peter Kokot

7 years ago
Hello, On Mon, 4 Mar 2019 at 03:10, Steven Penny <svnpenn@gmail.com> wrote:
> > On Mon, 04 Mar 2019 01:58:35, Stanislav Malyshev wrote: > > It does not matter what you did before. It's not a "who spit on whom > > first" discussion in a kindergarten. It's "you don't use this kind of > > language here, period" discussion on this list. If you can't abide by > > that, please use some other list. That's it. > > again, wrong. this list *is* kindergarten, as even PHP devs treat it that way, > as ive demonstrated. > > if you wish to disregard the evidence i provided of that, its your business. > same as if you decide to ban me. i would rather you not, but frankly at this > point it doesnt seem like a loss. > > cheers > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
With this level of arrogance I'm not sure anything would go through even if you payed someone to add such a feature. At least I know that I wouldn't put up with such client or a colleague for very long... If you have put zero effort in investigating issue and how to proceed with such a feature request/idea even after getting instructions how to proceed things won't move in any direction unless someone makes a function for this. In open source world a lot of more adjustments is needed. After more respect to one another will be shown, maybe we can move on to discussing what is the better way to output a string and a newline character included by default. Now, interesting is that in bash and some langs (where the main environment is CLI), there is by default newline echoed. In PHP and other languages there isn't. Changing default functionality of echo in PHP is like changing left-hand traffic countries to use right-hand traffic. A new function name would be needed for that. You can start with creating an extension for this... But with this level of communication? Hm...
-- Peter Kokot

Sara Golemon

7 years ago
On Sun, Mar 3, 2019 at 6:45 PM Stanislav Malyshev <smalyshev@gmail.com> wrote:
> This is not Twitter and not any > other forum where such things are welcome. >
I want to apologize for my behavior on this thread. I know you're directing your message at another party, but I was churlish and instigative. I really should have exercised more patience and decorum, and for that I'm sorry. -Sara

Rowan Collins

7 years ago
On Mon, 4 Mar 2019 at 04:31, Sara Golemon <pollita@php.net> wrote:
> On Sun, Mar 3, 2019 at 6:45 PM Stanislav Malyshev <smalyshev@gmail.com> > wrote: > > > This is not Twitter and not any > > other forum where such things are welcome. > > > > I want to apologize for my behavior on this thread. I know you're directing > your message at another party, but I was churlish and instigative. I really > should have exercised more patience and decorum, and for that I'm sorry. >
Hi Sara, Thanks for owning your mistake. There's definitely a temptation to be dismissive when a new user raises a suggestion that seems "obviously" untenable, either because it's been discussed to death already, or there's a flaw they haven't considered, because engaging can feel like "a waste of time". It's a shame when this ends up chasing away users who make those suggestions in good faith, rather than encouraging them to learn and contribute more. One problem is that we don't really have anywhere to direct new users - we can tell them to raise an RFC rather than continuing the discussion, but that doesn't really solve anything. What we really need is a way of welcoming people, and giving them an idea of which ideas are more likely to be popular, and how to frame them to avoid immediate objections. At the moment, you can only really find that out by lurking on the list for about a year. I've thought before about putting together some kind of FAQ; the biggest problem would be representing previous discussions without making them feel like solid policies; it should be "here are some objections that are likely to be raised", not "here are the reasons you can never do this ever". Regards,
-- Rowan Collins [IMSoP]

Rowan Collins

7 years ago
On 02/03/2019 19:59, Steven Penny wrote:
> 3. Add a new method, perhaps "echoln", "println", "say" or similar, > that outputs >   a newline by default
Of the suggestions put forward, this is the only one I can see having any chance of succeeding. However, I think the big reason this doesn't already exist is one that's been touched on by other responses: PHP started as, and is still primarily regarded as, a language for building websites. In that context, newline characters are generally considered "insignificant whitespace"; the closest equivalent would be appending '<br>' or '<br />' (depending on the dialect of HTML in use), but you're as likely to want "<p>$foo</p>", or "<li>$foo</li>", etc - and that's before we get into the tricky topic of escaping. Even in CLI scripts, as soon as you're building anything intended for reuse, you're likely to write a function like log_string() which adds information like timestamp, category, severity. The use cases for a new function / keyword may therefore be rather limited. Regards,
-- Rowan Collins [IMSoP]