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 <BR>. Those who use it on
shell will pick \r|\r\n|\n or simply \R. So, web server environments,
such as XAMPP, can set <br> end of line eliminator in the INI file
that they provide.
Example:
<?php
ini_set('println.eol', EOL_UNIX);
println('Hi PHP,');
println();
println('Regards');
?>
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:
<?php
$content = file_get_contents(__FILE__);
foreach (str_split($content) as $index => $char):
printf("$index=$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 <rowan.coll...@gmail.com> 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#phannoopbinaryoperator
>
>
> 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() ) // does what it
>>> looks like, if println is a normal function
>>> if ( something() && print($foo) && somethingElse() ) // 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
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
