Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113529 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 94698 invoked from network); 15 Mar 2021 02:58:17 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 Mar 2021 02:58:17 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B540D1804D0 for ; Sun, 14 Mar 2021 19:51:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com [209.85.221.181]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 14 Mar 2021 19:51:41 -0700 (PDT) Received: by mail-vk1-f181.google.com with SMTP id 11so2524785vkx.6 for ; Sun, 14 Mar 2021 19:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3ghJ50IRNhBBkiNcz8u5KbAXyg20r3IyKPOsAgMIoUk=; b=BO0vUPuoirMQ5fCiWR/5IOxRSArtHsgNLpoa9I9VVkzzuZ+1bN+O4Wn7yv2SEffM5e H7VZP7Jce7LTaNtqsv3y5W+PY97T85DPQ5n0x+Aa+jKOuC7dkL1y47LXGzrZ/zQi/V2+ qFF6ieMhUw1nzzUQgRRgM6sx1n0nt2epCWayor9hdCsd2nbMyRbWbbG/7nMEvmYS7CHS rf8vNi5wvmzXMFjnIVZl02jVgO2DNgSaWVmu+iLroYT3SHdILmt2kW0EmbM6MoFwYQ2o m3xy28z97gXgJrQ2h+XWuvuEweBZQmElRgi5qZOo/UrHiJk2o4BQSh4gA1HVsH03pwIF Xaag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3ghJ50IRNhBBkiNcz8u5KbAXyg20r3IyKPOsAgMIoUk=; b=V352pXLbupUDqSwqyuoY/tkYj5svUIfEhCa/KLYUZ7Rrjf9X4Wz9Dk3R/9TPjv7zAh JrneJIRs8dTl6cYQLgr19pcQT17oXsTvaY/ZJCyb6UjfMTCwMB2ENy3tv81QXDUWMfb8 xY9yLRk8RP/T+dNPKRp+9DjtDLEkPjR5XKO0ktOznEiNE6FKp0jZC0B+3+VMrxx2ynr8 5pdcjPdFsDDT1cX+12XD4yD0ENbDDp6fm/tX+fCcdcwZUBwuObxgd9J19aD80nUDMBey L/ooPbYiD4KvF6zJnmy40j7yS/GHVDsrIY2hfISxO6AoIRQa831StIRn40DlwpJhgD+n eSYw== X-Gm-Message-State: AOAM531P75W5M5KOb2xFauLdziMqouzH6Fk9S2qWKAZKvG7wTpzpWfKz M6eIJtPYCYEoJBFmnjbaGDDKn7MYR0pdZEN1KKA= X-Google-Smtp-Source: ABdhPJzMXJNCGOFgp2gPDO4auszFSf2TE3QvRAMHFmsLKuN9z74XvoeyUQRWGbQ7a85aKRhR6dpPyv0tVg3VHoPnM9Q= X-Received: by 2002:a1f:2d09:: with SMTP id t9mr3534130vkt.3.1615776698890; Sun, 14 Mar 2021 19:51:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:3a86:0:0:0:0:0 with HTTP; Sun, 14 Mar 2021 19:51:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Mar 2021 07:51:38 +0500 Message-ID: To: Rowan Tommins Cc: internals@lists.php.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] RFC: Add `println(string $data = ''): int` From: office.hamzaahmad@gmail.com (Hamza Ahmad) Hi, I have two questions regarding the RFC. 1. Why not provide an another optional attribute that allows to specify the end of line eliminator? 2. Why don't you configure Unix end of line in INI file? These additional steps will help users choose their favorite end of line for their projects. The INI settings should be INI_ALL, so libraries for various contexts can alter the attitude. For example, those who learn PHP in web browsers can use
. Those who use it on shell will pick \r|\r\n|\n or simply \R. So, web server environments, such as XAMPP, can set
end of line eliminator in the INI file that they provide. Example: Besides, Let me give a strange circumstance that gives inappropriate result if Unix end of line is used on old windows machine. Observe the following lines written to shell. php test.php>test.txt&test.txt The contents of test.php file: $char): printf("$index=3D$char\n"); endforeach; ?> Test.txt file will open in windows notepad. Here comes a bug that did not display Unix end of lines properly in old 7 machines and 8.1 machines. It was fixed in the recent tweaks to Notepad. Will PHP developers support only windows 10 and ignore the privious OSs? I also suggest creating end of line constants as integer's, so nobody could mistakenly write following: println('Hae, this is my test message.', ''); As for naming constants, I suggest using the following scheme: EOL_DEFAULT, EOL_PHP, EOL_CR, EOL_LF, EOL_CRLF, and EOL_HTML. Because there appeared an RFC that requested to Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON. Why not fix this issue before it emerges? Additionally, multiple constants can be provided, too. EOL_UNIX and EOL_LF may have same value. The similar case applies to EOL_MAC and EOL_WINDOWS. Regards On 3/14/21, Rowan Tommins wrote: > On 14/03/2021 15:52, tyson andre wrote: > >> There's also the alias fputs >> ofhttps://www.php.net/manual/en/function.fwrite.php >> which also returns the byte count. > > > Notably, like printf(), that is borrowed directly from C, and probably > dates from a time when most PHP programmers were also C programmers. > That time is long past. > > >> Annoyingly, any decision I make would be inconsistent with something > > > I'm not sure why you're casting your net so wide. The name and use cases > for this function put it squarely next to "print" and "echo" in my mind, > and it would never occur to me to ask if it was consistent with most of > the functions you've mentioned. > > >> It definitely would be longer to use `println((string)$foo)`, >> but there may be cases where that would be done, >> e.g. if you are writing a script that would be reviewed/modified/used by >> programmers that are more familiar with languages that aren't PHP. >> (It'd be more readable using 1 output method than 3) > > > Sorry, I'm not sure what you mean here. What 3 output methods are you > talking about, and how does println((string)$foo) make a difference to > them? > > >> There's also `println("$foo");` > > > Which is still marginally longer than the existing print "$foo\n"; > > >> Static analyzers for PHP such as Phan warn about the unused result of >> multiplication >> to catch cases like this, and other analyzers can easily add this check = if >> they don't already check for it. >> https://github.com/phan/phan/wiki/Issue-Types-Caught-by-Phan#phannoopbin= aryoperator > > > That doesn't stop it being a nasty surprise. People will want to use > "print" and "println" interchangeably, and making that difficult because > they have different syntax is going to end up on lists of "things I hate > about PHP", no matter how easily tools can spot it. > > >>> if ( something() && println($foo) && somethingElse() )=C2=A0 // does wh= at it >>> looks like, if println is a normal function >>> if ( something() && print($foo) && somethingElse() )=C2=A0 // does not = print >>> $foo, because the expression passed is actually ($foo)&&somethingElse() >> The fact that `print` doesn't require parenthesis is something that >> surprised me initially, > > > Just to be clear, it is not that print doesn't *require* parentheses, > it's that print does not have parentheses, ever. > > >> though changing it to force it to use function syntax would be a much >> larger bc break >> more suitable for a major version, that I don't expect to pass. > > > It hadn't even occurred to me to suggest that. I was suggesting the > opposite: if we add something called "println", it should have identical > syntax and behaviour to "print". The only difference should be the extra > newline character in the output. > > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >