Re: [PHP-DEV] print with newline
Sara, where do I send pull requests? wrote: > 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;` >
Re: [PHP-DEV] print with newline
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;`
Re: [PHP-DEV] print with newline
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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] print with newline
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 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.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] print with newline
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] print with newline
On Sat, Mar 2, 2019 at 1:59 PM Steven Penny wrote: > with PHP, several methods are available to produce output: > [[::snip::]]
Re: [PHP-DEV] print with newline
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 "" 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] print with newline
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 "" 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] print with newline
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
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Consistent type errors for internal functions
On 1 March 2019 12:02:29 GMT+00:00, Christian Schneider wrote: >I have an example where this might be harder than necessary: >I'm importing data from an external source. Now in the real-world the >import data files can once in a blue moon contain bogus data, e.g. >there could be an array instead of a string in one single entry and I'm >doing a strlen() on it. > >Previously this triggered a Warning but the import job completed for >all the other entries while still informing me that something was >amiss. The problem with Warnings is that processing doesn't just continue for all the *other* entries, it continues with *this entry that turned out to be bogus*. So now rather than a missing record, you have a record containing a 0, or the word "array", etc; and the Warning probably won't tell you which record it was that failed. >The new way leaves me with three options: >1) My import jobs stops at the single broken entry >2) I can add type-checks for every single field >3) I can start wrapping code with try/catch Option 2 can be stated differently as "add validation for each input record": this isn't the same kind of type check as a library function picking up coding mistakes, it's handling of untrusted input. Option 3 can be thought of as the transactional approach: if an error happens within a logical record, you can log that record to a reject file and continue with the next record. There is definitely more effort to doing one of these compared to not doing it, but both seem preferable to letting bad data through, whether the language forces you to do something or not. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
