20:28 Thomas Punt, wrote:
> > From: Steven Penny
> > Sent: 04 March 2019 15:30
> > To: internals@lists.php.net
> > Subject: Re: [PHP-DEV] print with newline
> >
> > I think the best option is a new function like "puts" or "posix_puts".
&g
> From: Steven Penny
> Sent: 04 March 2019 15:30
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] print with newline
>
> I think the best option is a new function like "puts" or "posix_puts".
I'm fairly neutral on the feature, but I disagree
On Mon, Mar 4, 2019 at 11:25 AM Johannes Schlüter
wrote:
> On Mo, 2019-03-04 at 07:30 -0800, Steven Penny wrote:
> > On Mon, 04 Mar 2019 02:23:46, Peter Kokot wrote:
> > >
> > > Now, interesting is that in bash and some langs (where the main
> > > environment is CLI), there is by default newline
On Mo, 2019-03-04 at 07:30 -0800, Steven Penny wrote:
> On Mon, 04 Mar 2019 02:23:46, Peter Kokot wrote:
> >
> > 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
Afternoon Steven,
I'm not going to apologize for making a joke ... it was a joke ...
That being said, if you insist on pursuing an RFC for this, and would like
to get on with writing that RFC, then here is an initial patch:
https://gist.github.com/krakjoe/efff492611ce8f9fc12909023c89c7dc
Let com
On Mon, 04 Mar 2019 02:23:46, Peter Kokot wrote:
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 countr
On Mon, 4 Mar 2019 at 04:31, Sara Golemon wrote:
> On Sun, Mar 3, 2019 at 6:45 PM Stanislav Malyshev
> 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
On Sun, Mar 3, 2019 at 6:45 PM Stanislav Malyshev
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
Hello,
On Mon, 4 Mar 2019 at 03:10, Steven Penny 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" discussi
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
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 t
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 d
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 sh
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.
Ho
On Sat, Mar 2, 2019 at 10:26 PM 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 packag
On Sun, 3 Mar 2019 at 22:43, G. P. B. wrote:
> On Sun, 3 Mar 2019 at 22:24, Ryan Jentzsch
> wrote:
>
>> With semantic versioning b/c is allowed. For example version 8.0.0 vs
>> 7.x.x
>> -- version 8.0.0 could include major breaking changes (since it is a major
>> version number change). This al
Hi
Den søn. 3. mar. 2019 kl. 23.24 skrev Ryan Jentzsch :
>
> With semantic versioning b/c is allowed. For example version 8.0.0 vs 7.x.x
> -- version 8.0.0 could include major breaking changes (since it is a major
> version number change). This allows a language to evolve and grow with the
> need
With semantic versioning b/c is allowed. For example version 8.0.0 vs 7.x.x
-- version 8.0.0 could include major breaking changes (since it is a major
version number change). This allows a language to evolve and grow with the
needs of the users.
If PHP is so `rigid` that NO B/C are allowed (regard
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
On So, 2019-03-03 at 14:33 +, 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
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 alre
Penny
发送时间: 2019年3月3日 21:53
收件人: internals@lists.php.net
主题: Re: [PHP-DEV] print with newline
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
&
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 alr
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":
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 corre
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
wrote:
> Steven, Ryan,
>
> Adding new functions is also considered BC break because users might have
> those functions in their code.
> Over the years new functions
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 b
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 stat
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` / `s
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 Internal
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_E
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
On Sat, Mar 2, 2019 at 1:59 PM Steven Penny wrote:
> with PHP, several methods are available to produce output:
> [[::snip::]]
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
impleme
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 "prin
35 matches
Mail list logo
