(sorry for top posting)
Hi Nikita,
as for the question about magic methods vs. interface.
I have the feeling that it could be done with both in a clean way to
make both parties happy.
1. Having __serialize/ __unserialize as magic methods - allowing to
throw exceptions also to explicitly
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
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"
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
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
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
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
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.
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
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
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
>
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
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
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
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
If you really believe you are proposing something meaningful, here [1] is a
guide for you to make some changes in php kernel. However I don't think you
can win the vote since the response is bad so far.
[1]: https://wiki.php.net/rfc/howto
Regards,
CHU Zhaowei
-邮件原件-
发件人: Steven Penny
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
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
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
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
21 matches
Mail list logo
