of the
arguments for in_array and strpos, just had to look it up again.
Bob would volunteer to implement that feature.
Best Regards
Niklas Keller
2015-01-20 6:35 GMT+01:00 Pierre Joye pierre@gmail.com:
On Tue, Jan 20, 2015 at 6:15 AM, Andrea Faulds a...@ajf.me wrote:
Hi Mike,
On 20 Jan 2015, at 03:30, Mike Willbanks pen...@gmail.com wrote:
I am very familiar with the in operator. However, the implementation
would be incomplete
Hi internals,
In Operator is now in discussion phase.
This RFC adds a new in operator which simplifies contains checks for strings
and arrays.
Currently, we have to usein_array($needle, $haystack, true) or
strpos($haystack, $needle) !== false.
These functions have a inconsistent parameter
a good book. (Devo dizer que acho televisão
muito educativo. Quando alguém a liga, vou à biblioteca e leio um bom
livro.)
(Groucho Marx)
On Sat, Mar 14, 2015 at 9:54 PM, Niklas Keller m...@kelunik.com wrote:
Morning,
I'd like to announce that I'll open the vote for the in operator later
2015-03-14 23:30 GMT+01:00 Rasmus Lerdorf ras...@lerdorf.com:
On 03/15/2015 07:31 AM, Philip Sturgeon wrote:
On Sat, Mar 14, 2015 at 7:38 AM, Bob Weinand bobw...@hotmail.com
wrote:
Am 14.03.2015 um 10:21 schrieb Pavel Kouřil pajou...@gmail.com:
On Saturday, March 14, 2015, Levi Morrison
Morning,
I'd like to announce that I'll open the vote for the in operator later that day.
You can find the RFC here: https://wiki.php.net/rfc/in_operator
There was a small change: If the haystack is a string, integers are no
longer allowed as needle. This change was necessary so it's
2015-03-15 3:34 GMT+01:00 Stanislav Malyshev smalys...@gmail.com:
Hi!
I'd like to announce that I'll open the vote for the in operator later that
day.
You can find the RFC here: https://wiki.php.net/rfc/in_operator
I think this operator is unnecessary - we already have perfectly good
2015-03-15 21:13 GMT+01:00 Damien Tournoud d...@damz.org:
Hi Daniel,
Would you mind clarifying the relationship between the Generator
Delegation RFC and the Generator Return Expressions RFC?
While I really appreciate the Generator Delegation RFC, the Generator
Return Expressions looks both
Morning,
I just opened the vote for the in operator, you can find the RFC here:
https://wiki.php.net/rfc/in_operator
Vote will be open for two weeks, counting from today.
Regards, Niklas
2015-03-15 19:13 GMT+01:00 Levi Morrison le...@php.net:
On Sun, Mar 15, 2015 at 12:03 PM, Bob Weinand bobw...@hotmail.com wrote:
Am 15.03.2015 um 18:48 schrieb Anthony Ferrara ircmax...@gmail.com:
Andrea's RFC had the following wording:
The only exception to this is the handling of NULL: in
2015-03-21 8:25 GMT+01:00 Pierre Joye pierre@gmail.com:
On Mar 21, 2015 2:15 PM, Levi Morrison le...@php.net wrote:
I know that many people here will say that it’s not that important
developers get used to this API and many tutorials based on it.
As you guessed, I don't think
You have to input internals@lists.php.net, that changed some time ago.
I've just updated https://wiki.php.net/rfc/howto
See
https://github.com/php/web-wiki/commit/583d2c1b39a8b88960ab94e56ba4a4608ddb2353
Regards, Niklas
2015-03-11 14:43 GMT+01:00 Johannes Ott m...@deroetzi.de:
Am 11.03.2015 um
2015-03-12 12:33 GMT+01:00 Johannes Ott m...@deroetzi.de:
Am 12.03.2015 um 12:16 schrieb Crypto Compress:
Hello Johannes,
class Foo {
private static function __static() {
throw new Exception(boom);
}
}
while(true) {
try {
$foo = new Foo;
}
This RFC has been declined with 21 Yes votes and 26 No votes.
Regards, Niklas
2015-03-29 11:19 GMT+02:00 Pascal Martin, AFUP mail...@pascal-martin.fr:
Le 15/03/2015 20:31, Niklas Keller a écrit :
I just opened the vote for the in operator
Hi,
Discussing this RFC with other people at AFUP
2015-03-03 13:27 GMT+01:00 Rowan Collins rowan.coll...@gmail.com:
Bob Weinand wrote on 03/03/2015 12:08:
Am 03.03.2015 um 12:34 schrieb Rowan Collins rowan.coll...@gmail.com:
Niklas Keller wrote on 03/03/2015 10:55:
Gr, top-posting...
Sorry, was on mobile. ;-)
However, since
2015-03-02 11:11 GMT+01:00 Bob Weinand bobw...@hotmail.com:
Am 02.03.2015 um 01:17 schrieb Niklas Keller m...@kelunik.com:
2015-03-02 0:52 GMT+01:00 Daniel Lowrey rdlow...@php.net:
Hi folks,
I'd like to initiate discussion on a proposal to implement generator
delegation via
I prefer yield from, because it yields that value from the generator. Yield
use doesn't make any sense to me if I read those words.
Additionally, it's already used by another language.
Regards, Niklas
Daniel Lowrey rdlow...@php.net schrieb am Mo., 02.03.2015, 17:13:
From initial discussions
If we introduce those new aliases, it should be clearly stated in the docs
which function should be used, maybe we can remove the old one in the far
future then. But the more important point is, that it's not that confusing
to users. Which one should I use? Why's there another one? We already have
2015-03-02 0:52 GMT+01:00 Daniel Lowrey rdlow...@php.net:
Hi folks,
I'd like to initiate discussion on a proposal to implement generator
delegation via the following new syntax inside generator functions:
yield * expr
The Generator Delegation RFC is available here:
Gr, top-posting...
Sorry, was on mobile. ;-)
However, since the existence of the word yield is the only thing that
marks a coroutine now, how about using a variant of that for the final
value, e.g. yield final $foo?
What's the final value? The last yielded value or a return?
Just to
2015-03-03 12:34 GMT+01:00 Rowan Collins rowan.coll...@gmail.com:
Niklas Keller wrote on 03/03/2015 10:55:
Gr, top-posting...
Sorry, was on mobile. ;-)
However, since the existence of the word yield is the only thing that
marks a coroutine now, how about using a variant
2015-02-21 1:07 GMT+01:00 Pádraic Brady padraic.br...@gmail.com:
On 20 February 2015 at 23:38, Larry Garfield la...@garfieldtech.com
wrote:
While I love the idea, strict type comparison for in would, in essence,
be a
toe-dip into the scalar strict typing world (see other thread) that
would be
2015-02-21 1:23 GMT+01:00 Yasuo Ohgaki yohg...@ohgaki.net:
Hi all,
On Sat, Feb 21, 2015 at 2:55 AM, Sara Golemon poll...@php.net wrote:
Announcing this in its own thread:
https://wiki.php.net/rfc/reserve_even_more_types_in_php_7
This RFC acts as an addition to Levi's
2015-02-21 1:45 GMT+01:00 Niklas Keller m...@kelunik.com:
2015-02-21 1:07 GMT+01:00 Pádraic Brady padraic.br...@gmail.com:
On 20 February 2015 at 23:38, Larry Garfield la...@garfieldtech.com
wrote:
While I love the idea, strict type comparison for in would, in essence,
be a
toe-dip
2015-02-20 19:48 GMT+01:00 Markus Fischer mar...@fischer.name:
On 20.02.15 18:16, Dan Ackroyd wrote:
On 20 February 2015 at 12:54, Niklas Keller m...@kelunik.com wrote:
Hi internals,
It would really make sense to vote on this RFC after there has been a
vote on https://wiki.php.net/rfc
Hi Nikita,
I like the new display format, but there's one thing I miss. If you replace
the exception name for warnings and fatals, how does a user know which
exception he has to catch?
Regards, Niklas
Nikita Popov nikita@gmail.com schrieb am Do., 09.04.2015, 10:04:
Hi internals!
A lot
2015-07-04 22:56 GMT+02:00 Sherif Ramadan theanomaly...@gmail.com:
Hey guys,
I'm proposing that we reconsider removing the warning from floating point
division and here's why.
While IEEE 754 defines special values for floating point arithmetic when
division by zero occurs, there's nothing
2015-07-07 2:22 GMT+02:00 Pierre Joye pierre@gmail.com:
hi Aaron,
On Mon, Jul 6, 2015 at 1:15 PM, Aaron Piotrowski aa...@icicle.io wrote:
Hello everyone!
I recently pushed changes that eliminated E_EXCEPTION and allows an
exception type to be provided for what were fatals in PHP,
This is intended and documented here:
http://php.net/manual/en/function.set-exception-handler.php
Regards, Niklas
2015-08-17 12:31 GMT+02:00 Christian Weiske cwei...@cweiske.de:
Hi,
We're trying to use TYPO3 on PHP7 and have the problem that throwables
get passed to the exception handler
What do you guys do in the set_exception_handler callback? Wouldn't most
code just use the same callback and just log the error / exception?
Regards, Niklas
2015-08-19 11:55 GMT+02:00 Björn Larsson bjorn.x.lars...@telia.com:
Den 2015-08-19 kl. 10:52, skrev Peter Cowburn:
On 17 August 2015 at
I agree with this completely. I think the point here is that
catch(Exception $e) remains unchanged while setting a handler actually
catches more things now. Tbh I feel like this is an oversight in
implementing the Error/Throwable rfc and should be addressed now, otherwise
it can't be changed
It surely won't be the last one. I am not keen to keep adding or
changing things
like that at this stage, given the tough timeline.
Yeah, there are quite some topics yet which unfortunately cannot be
resolved properly in the given time frame till 7.0 final. With regard to
that, better
I guess people continue to use rand() or mt_rand() if they skip the
documentation.
Even frameworks which are advertised with 100% php7 compatibility use
mt_rand().
There's nothing wrong with mt_rand() in non-security contexts, it's still
there in PHP 7. If anyone is using mt_rand() in
why not have false + e_warning for strict_types=0 and fatal error for
strict_types=1 ?
Doing function random_int(): int { ...
How's this connected to `strict_types`? It's not.
If people use this function without reading documentation, they will also
use other things without documentation
2015-07-30 14:42 GMT+02:00 Andone, Bogdan bogdan.and...@intel.com:
-Original Message-
From: Niklas Keller [mailto:m...@kelunik.com]
Sent: Thursday, July 30, 2015 1:47 PM
To: Pierre Joye
Cc: lp_benchmark_robot; PHP internals; l...@lists.01.org
Subject: Re: [PHP-DEV] Benchmark
2015-08-02 14:32 GMT+02:00 Markus Malkusch mar...@malkusch.de:
Dor Tchizik wrote:
Currently, PHP discussions are held on the various mailing lists, managed
by an old mailing list system, without any proper alternative interface
to
follow and respond outside of mailing.
What wrong with
2015-08-02 15:29 GMT+02:00 Rowan Collins rowan.coll...@gmail.com:
On 2 August 2015 13:54:46 BST, Niklas Keller m...@kelunik.com wrote:
We're discussing issues here, so what's wrong with an issue tracker?
No, we're discussing every aspect of the project, from release management
to personal
2015-08-02 16:48 GMT+02:00 Andreas Heigl andr...@heigl.org:
Hi Niklas
Am 02.08.2015 um 16:26 schrieb Niklas Keller m...@kelunik.com:
2015-08-02 15:29 GMT+02:00 Rowan Collins rowan.coll...@gmail.com:
On 2 August 2015 13:54:46 BST, Niklas Keller m...@kelunik.com wrote:
We're
I remember it being pretty trivial - enter my e-mail address, verify my
e-mail address, skim-read the etiquette doc, start discussing.
I agree with that. Getting RFC karma isn't that hard, at least not if your
mail doesn't get lost during hot discussions.
If you're not interested in a
2015-07-31 23:36 GMT+02:00 Yasuo Ohgaki yohg...@ohgaki.net:
Hi Niklas,
On Fri, Jul 31, 2015 at 7:20 PM, Niklas Keller m...@kelunik.com wrote:
Using set_error_handler isn't handling errors gracefully. Well, it's
better than E_ERROR, but then libraries can't handle those errors
gracefully
2015-08-01 1:43 GMT+02:00 Yasuo Ohgaki yohg...@ohgaki.net:
Hi Niklas,
On Sat, Aug 1, 2015 at 8:27 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
They should totally be handled. You need to catch the error and throw a
defined exception, otherwise your public API will break if you choose to
use
What's the point of having it in the core? You already created a library in
userland that can be used by other projects if they need support for it.
Regards, Niklas
2015-07-29 15:05 GMT+02:00 Samson Endale 4sa...@gmail.com:
can i have a response please!
On 5/31/15, Samson Endale
2015-07-30 19:12 GMT+02:00 Scott Arciszewski sc...@paragonie.com:
On Mon, Jul 27, 2015 at 2:03 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
Rowan,
This is certainly some people's concern, but Anatol has raised a subtly
different consistency-related point, which is this:
Since we
...@ohgaki.net:
Hi Niklas,
On Fri, Jul 31, 2015 at 5:12 PM, Niklas Keller m...@kelunik.com wrote:
I think the question is more whether Exception or Error (class, not
E_RECOVERABLE_ERROR), to allow handling it gracefully.
E_WARNING is too weak for CSPRNG not available.
It's fatal error.
I agree
2015-07-30 11:57 GMT+02:00 Pierre Joye pierre@gmail.com:
Hi,
Does someone has a contact there?
It would be nicer to have these results combined with what we pushed on
qa.php.net as well.
Cheers,
Pierre
Thought about that as well, results per mail aren't that useful, especially
as
Okay, great, we have people on both sides on this discussion. I hope
nobody minds if I sit this part out.
What specifics need to be discussed? Should somebody set up a poll? (I
don't know how to do that.)
You can find information on how to setup a poll in step 6 here:
Scott, could you setup a RFC with a vote, so we can decide?
Nikita proposed those two options:
1) Error is to be used in cases where an error is attributable to
programmer mistake.
2) Error signifies a failure condition that the programmer is discouraged
(and unlikely to want) to handle. It
So my question here is - how important task is switching crypto backends
easily? Moreover, what would be the reason for me, as an app developer,
to target more than one crypto backend? I can see why I may want to
target mysql and say, SQL server - these two platforms have different
2015-11-09 17:46 GMT+01:00 Leigh <lei...@gmail.com>:
>
> On 9 November 2015 at 16:42, Niklas Keller <m...@kelunik.com> wrote:
>
>>
>> Having the path info is quite useful for debugging purposes.
>>
>> Regards, Niklas
>>
>
> It is, but
2015-11-09 16:27 GMT+01:00 Steven Hilder <
steven.hilder@sevenpercent.solutions>:
> On Thu, 05 Nov 2015 15:14:47, Leigh wrote:
>
>> On 5 November 2015 at 14:59, Rowan Collins
>> wrote:
>>
>>> PHP uses null bytes quite a lot to produce deliberately
2015-11-11 14:44 GMT+01:00 Derick Rethans :
> On Wed, 11 Nov 2015, Nikita Popov wrote:
>
> > Using a NUL byte conveniently achieves both of these goals. We did not
> > however take into account that this would cause issues with 3rd party
> > tooling that does not support binary
Hello,
I discovered today that anonymous class names contain a null byte right
after "class@anonymous". I don't think class names should contain
non-printable characters.
How about removing that null byte?
https://3v4l.org/QUKpV
Problem is that e.g. exception to string casts do not handle it properly,
there may be other affected areas.
https://3v4l.org/e9AGZ
Regards, Niklas
2015-11-05 16:14 GMT+01:00 Leigh :
> On 5 November 2015 at 14:59, Rowan Collins
> wrote:
>
> >
> > PHP
Hi Björn,
Ah yes, then a set_throwable_handler would be needed. A final question:
Would it
be an alternative to update set_error_handler to also handle
\Throwable\Error\*
exceptions and let set_exception_handler catching same type of exceptions
like
in PHP 5?
set_error_handler handles
QA and ready builds are important, but why is it tagged after all if it
might be retagged if any issues occur? Why isn't it frozen to a specific
commit but not tagged (via a public pushed tag) until everything is ready?
I understand that people really want PHP 7, but let's get it out
Hi Netroby,
> I wrote a small test. to see if it really concurrent processing any tasks.
> the result looks bad. Still single blocking thread.
>
As the RFC already states:
The actual implementation of coroutine task schedulers is outside the scope
> of this document. This RFC focuses only on
Jan Ehrhardt schrieb am Do., 3. Dez. 2015 17:04:
Ferenc Kovacs in php.internals (Thu, 3 Dec 2015 16:27:36 +0100):
>On Thu, Dec 3, 2015 at 4:18 PM, Sebastian Bergmann
>wrote:
>
>> Am 03.12.2015 um 16:10 schrieb Julien Pauli:
>> > We, PHP, are not distros
Yes, releases have been repackaged, see
https://mta.openssl.org/pipermail/openssl-announce/2015-December/51.html
Regards, Niklas
2015-12-03 21:47 GMT+01:00 Rasmus Lerdorf <ras...@lerdorf.com>:
> On 12/03/2015 09:39 AM, Niklas Keller wrote:
> > Jan Ehrhardt <php...@ehrhardt
It still seems to be missing from the download section in the right sidebar.
Anyway, thanks everyone!
2015-12-03 21:35 GMT+01:00 Carlos Buenosvinos Zamora <
carlos.buenosvi...@gmail.com>:
> Congrats to everyone. Thanks for such an amazing work! I'm really proud to
> be in such a great
2015-12-03 22:22 GMT+01:00 Ferenc Kovacs <tyr...@gmail.com>:
>
>
> On Thu, Dec 3, 2015 at 10:00 PM, Niklas Keller <m...@kelunik.com> wrote:
>
>> It still seems to be missing from the download section in the right
>> sidebar.
>>
>> Anyway, tha
>
> 3. (Fatal error on many collisions). While the two previous options try to
> ensure that hashtables stay efficient regardless of the used keys, the last
> option aims to simply detect malicious array keys and abort the script in
> such a case.
>
> This is done by counting the number of
Currently it's not catchable, that's my main concern. If it's catchable,
it's not that much of a problem.
Regards, Niklas
2015-11-27 10:05 GMT+01:00 Yasuo Ohgaki :
> Hi Nikita,
>
> On Fri, Nov 27, 2015 at 2:24 AM, Nikita Popov
> wrote:
> > What are
2015-11-30 14:49 GMT+01:00 Chris Riley :
> Anyone else getting an invalid cert on https://pear.php.net ?
>
Yes and it points to cweiske.de. PHP's certs are also "broken" for
svn.php.net and edit.php.net, there are browser warnings because of the
SHA1 certificate signatures.
I can only agree with Phil here. +1 for 1 week RCs if we're aiming at Dec
3rd anyway.
Thanks, Niklas
2016-06-10 14:39 GMT+02:00 Marco Pivetta :
> As already mentioned on twitter, I voted "no" on this RFC as it currently
> stands. I might reconsider if following points are addressed:
>
> 1. __get semantics are not changed: let __get behave like it usually does,
> and let the
>
> Top-posting, since I'm taking off now.
>
> From outside the class, properties are not visible at all, so their types
> are un-important from outer scopes.
>
> echo $foo->bar; is not the same in instance method body or outside of the
> class.
>
>From outside it works just fine and doesn't
>
> Massive is a nice hyperbole here...
> Sure, you can check it manually… but why not just always check it manually
> then?
> You then loose possibilities to reflect on it, have static analysis rely
> on code only [currently you always have to check docblocks when it's not
> declared; definitely
>
> On Wed, May 25, 2016 at 10:30 AM, Joe Watkins
> wrote:
>
> > Morning Dmitry,
> >
> >> I made this check(s) to be invariant. You may like to do this
> > differently...
> >
> >I think this is what everyone expects, isn't it ?
> >
> >I did omit to mention that
>
> Hey Niklas,
>
> > Am 25.05.2016 um 18:21 schrieb Niklas Keller <m...@kelunik.com>:
> >
> >>
> >> Hi Niklas,
> >>
> >> Niklas Keller wrote:
> >>
> >>>
> >>> I disagree here. Properties are always n
2016-05-25 20:39 GMT+02:00 Fleshgrinder :
> In my opinion it should simply vanish along with its definition. I mean,
>
Usually, yes. But suddenly `private Type $foo` isn't reliable anymore if
unset is supported for typed properties, because the following would just
remove
Andrea Faulds <a...@ajf.me> schrieb am Mi., 25. Mai 2016 19:14:
> Hi Niklas,
>
> Niklas Keller wrote:
> >>
> >> There is a difference between not set and no meaningful value.
> >>
> >
> > In PHP, there's no such difference for
2016-06-10 16:12 GMT+02:00 Bob Weinand :
> In this case a definite -1 on the RFC from me. I don't want "surprises"
> regarding the type if a property is declared to return a certain type.
>
Where's the surprise?
2016-06-10 15:50 GMT+02:00 Bob Weinand <bobw...@hotmail.com>:
>
> Am 10.6.2016 um 15:34 schrieb Niklas Keller <m...@kelunik.com>:
>
>
> Top-posting, since I'm taking off now.
>
> From outside the class, properties are not visible at all, so their types
>
2016-06-15 19:38 GMT+02:00 Fleshgrinder :
> On 6/15/2016 12:27 PM, Alexander Lisachenko wrote:
> > For PHP7 we have pretty errors for almost everything, even eval can
> throw a
> > ParseError exception, but not for the require expression, because it's
> > still producing an
Scott Arciszewski schrieb am So., 5. Juni 2016 10:13:
> On Sat, Jun 4, 2016 at 6:15 PM, Stanislav Malyshev
> wrote:
> >
> > Hi!
> >
> > > Let's begin discussing the prospect of adding libsodium as a core
> extension
> > > in PHP 7.1. I've updated the
Bob Weinand schrieb am Fr., 3. Juni 2016 23:31:
>
> > Am 3.6.2016 um 18:49 schrieb Larry Garfield :
> >
> > On 06/03/2016 10:16 AM, Jordi Boggiano wrote:
> >> On 03/06/2016 15:58, Thomas Bley wrote:
> >>> To me type declarations help to make my code
2016-06-02 19:36 GMT+02:00 Fleshgrinder <p...@fleshgrinder.com>:
> On 6/1/2016 9:25 PM, Niklas Keller wrote:
> > Why does it directly extend throwable?
> >
> > Just a short node: the keys shouldn't be responsible for signing /
> > verification.
> >
>
>
2016-05-26 7:00 GMT+02:00 Stanislav Malyshev :
> Hi!
>
> > Also, property access never was safe. Consider:
> >
> > $obj = new class {
> > public $foo;
> > function __construct() {
> > unset($this->foo);
> > }
> > function __get($prop) {
> >
Fleshgrinder schrieb am Mi., 1. Juni 2016 19:26:
> On 6/1/2016 12:48 PM, Marco Pivetta wrote:
>
> > I also agree with Remi on naming: let's avoid calling the extension
> > `libsodium`.
> >
>
> I agree here too.
>
> On 6/1/2016 12:48 PM, Marco Pivetta wrote:
> > 1. is
Oh, just read the require example, didn't read it was planned for all file
functions.
Fleshgrinder <p...@fleshgrinder.com> schrieb am Mi., 15. Juni 2016, 19:57:
> On 6/15/2016 7:52 PM, Niklas Keller wrote:
> > I think it can go into 7.1. It's not a BC break, as it will
Fleshgrinder schrieb am Mi., 15. Juni 2016, 19:55:
> On 6/15/2016 1:30 AM, Tom Worster wrote:
> > On 6/14/16 3:12 PM, Fleshgrinder wrote:
> >
> >> Call me ignorant but is this required in typical web applications?
> >
> > PHP is used for various things, not just web apps.
2016-06-20 17:51 GMT+02:00 Rasmus Schultz :
> > My PHP is augmented with Smarty so I know which are template files and
> > which are program code :)
>
> I name my template files "*.view.php", so I know which is which.
>
> I also head off every file with /** @var MyViewModel
Rasmus Schultz schrieb am Sa., 18. Juni 2016, 17:44:
> > Add a couple parens and its completely implementable in userland
>
> If we could autoload functions, I bet that's what everyone would be doing.
>
> At the moment, no one is able to commit to that pattern, because it
>
>
> If something is required, one cannot do without it, so there's only one
> course of action, namely to bail out.
What about gracefully bailing out, like showing that composer dependencies
have to be installed?
It's just like a method call. Usually you expect a return value, unless
there's an
Lester Caine schrieb am So., 19. Juni 2016, 22:03:
> On 19/06/16 19:33, Михаил Востриков wrote:
> > Lester
> >
> >> > there is NO need to simply slap htmlspecialchars() onto
> >> > properly built data
> > There are many cases when user data can contain quotes or other html
>
Christoph Becker schrieb am Sa., 18. Juni 2016, 12:34:
> On 17.06.2016 at 19:58, Rowan Collins wrote:
>
> > On 17/06/2016 17:47, Christoph Becker wrote:
> >> If something is required, one cannot do without it, so there's only one
> >> course of action, namely to bail out. In
2016-06-20 11:12 GMT+02:00 Lester Caine <les...@lsces.co.uk>:
> On 20/06/16 07:00, Niklas Keller wrote:
> >> Now ... I want to add content that includes
> >> > alert("xss") it needs to be in the format
> >> > scriptalert(xss)script so th
2016-06-17 11:46 GMT+02:00 Christoph Becker :
> On 17.06.2016 at 10:29, Alexander Lisachenko wrote:
>
> > Nikita, Dmitry, ping. What do you think, shouldn't we replace all
> possible
> > places with Fatal Errors with correct throwing of Error exceptions? In
> > this concrete
Hi,
the issue is that things have to be escaped dependent on the context. If
you are in a HTML context you need different escaping than you need in a
CSS or JS block. The escaping should also be aware of the content encoding.
All that makes it difficult for PHP to directly support such an
2016-03-09 12:52 GMT+01:00 Derick Rethans :
> Hi!
>
> On Tue, 8 Mar 2016, Pierrick Charron wrote:
>
> > Bronisław Białek and I would like to start a discussion about allowing
> > multiple exception types to be caught in a single catch statement.
> >
> >
2016-03-30 21:04 GMT+02:00 Jakub Zelenka <bu...@php.net>:
> There is a PR for that https://github.com/php/php-src/pull/1686 that
> should land in 7.1 if there are no objections...
>
> On Wed, Mar 30, 2016 at 6:46 PM, Niklas Keller <m...@kelunik.com> wrote:
>
>>
Hi,
there's an open feature request with a patch since 2012, it's still against
SVN: https://bugs.php.net/bug.php?id=61204
Could somebody go ahead, review and merge that patch?
Thanks, Niklas
Readonly is already used in the documentation for some things in the DOM
book. Writeonce sounds strange.
Sebastian Bergmann <sebast...@php.net> schrieb am Sa., 9. Apr. 2016 15:52:
> Am 09.04.2016 um 12:55 schrieb Niklas Keller:
> > Another possible choice would be "re
Another possible choice would be "readonly".
>
> > I have got a port of the extension to work on OpenSSL 1.1. There has been
> > quite a bit of changes mainly due to the fact that most structures are
> now
> > opaque (but also some other changes)
>
> I assume 1.0.whatever-is-in-ubuntu will remain usable? Or do we plan on
> requiring 1.1 in,
The reason is probably that return types are currently invariant, so a
inheriting class would have to declare the parent as return type anyway.
Lee Davis schrieb am Di., 1. März 2016 12:46:
> Hi Internals,
>
> whilst recently playing with return type hints on PHP 7 I
Fleshgrinder schrieb am Mi., 27. Apr. 2016 22:11:
> I am writing this in a separate thread because of the urgency that I see
> regarding the naming of past, current, and future proposals regarding
> this functionality.
>
> It was and is proposed to create this feature with
2016-04-26 16:58 GMT+02:00 Bob Weinand :
> Yeah, I'd like to not allow ?Foo in any case if union types pass.
>
What's the reason for that? To me, null is neither a type nor should it be.
>
> I think that the Hack name attributes is unintelligible and annotations
>> would be much clearer to any audience. Simply because the name is very
>> well known.
>>
>
> Different languages names this differently.
> I may add an additional voting question - "annotation vs attributes?".
The
2016-04-26 19:33 GMT+02:00 Bob Weinand <bobw...@hotmail.com>:
> > Am 26.04.2016 um 19:00 schrieb Niklas Keller <m...@kelunik.com>:
> >
> > 2016-04-26 16:58 GMT+02:00 Bob Weinand <bobw...@hotmail.com>:
> >
> >> Yeah, I'd like to not allow ?Foo i
1 - 100 of 433 matches
Mail list logo