> it's just that no one except you thinks this is a good solution
it's just that no one - who is allowed to vote and wants to vote - thinks this
is a good solution.
Regards
Thomas
Rasmus Schultz wrote on 07.08.2016 13:06:
> Looks like it's unanimously a No.
>
> Michael, don't be discouraged
Hi Levi,
On Sat, Mar 19, 2016 at 5:56 AM, Levi Morrison wrote:
>> At least that's not what it says in the docs.
>
> I meant: at least according to the docs:
> http://php.net/manual/en/language.namespaces.rationale.php
>
>> Namespace names PHP and php, and compound names starting with these names
Hi all,
I disabled \r\n injections, that could override hole contents of mail,
by checking string extra headers for mail/mb_send_mail already.
Extra mail headers could be checked more by having array extra headers.
https://bugs.php.net/bug.php?id=69791
https://github.com/php/php-src/pull/2060
T
On Sun, Aug 7, 2016 at 12:32 PM, David Rodrigues
wrote:
> What should be the difference between a static method on a autoloaded
> class?
>
> I guess that it could be done currently by use a static method.
> In this case, I know exactly what method should be called, without
> depends of an autoloa
Hi Pierre, Niklas
On Sun, Aug 7, 2016 at 9:20 PM, Pierre Joye wrote:
> I would not rush it into 7.1.
On Mon, Aug 8, 2016 at 12:20 AM, Niklas Keller wrote:
> Isn't it a bit late to target 7.1 anyway?
I feel the same way indeed. However, it does not change existing
feature at all, but this is a p
On Sun, Aug 7, 2016 at 8:20 AM, Niklas Keller wrote:
> 2016-08-07 14:20 GMT+02:00 Pierre Joye :
>
> > On Aug 5, 2016 2:30 AM, "Yasuo Ohgaki" wrote:
> > >
> > > Hi Christian,
> > >
> > > On Thu, Aug 4, 2016 at 8:27 PM, Christian Stadler
> wrote:
> > > > Am 04.08.2016 um 12:10 schrieb Yasuo Ohgak
What should be the difference between a static method on a autoloaded class?
I guess that it could be done currently by use a static method.
In this case, I know exactly what method should be called, without
depends of an autoloader response.
class String {
public static function strpos(...)
On Fri, 2016-08-05 at 07:47 -0500, Charles R. Portwood II wrote:
> Hello Internals,
>
> Due to a couple issue with the original RFC's scope, the RFC for
> introducing Argon2 as an alternative hashing algorithm for the
> password_*
> functions was closed shortly after starting on Monday.
>
> The f
2016-08-07 14:20 GMT+02:00 Pierre Joye :
> On Aug 5, 2016 2:30 AM, "Yasuo Ohgaki" wrote:
> >
> > Hi Christian,
> >
> > On Thu, Aug 4, 2016 at 8:27 PM, Christian Stadler wrote:
> > > Am 04.08.2016 um 12:10 schrieb Yasuo Ohgaki:
> > >> Hi Christian and all,
> > >>
> > >> On Thu, Aug 4, 2016 at 10:
On 8/6/16, 1:55 PM, "Charles R. Portwood II"
wrote:
>Typically a run time of of under 50 ms is the target goal. Argon2 can be
>tweaked to use a specific amount of memory, time, or CPU cores. Trying to
>find good default cost factors is problematic since all 3 of those
>factors are variable on any
On Aug 5, 2016 2:30 AM, "Yasuo Ohgaki" wrote:
>
> Hi Christian,
>
> On Thu, Aug 4, 2016 at 8:27 PM, Christian Stadler wrote:
> > Am 04.08.2016 um 12:10 schrieb Yasuo Ohgaki:
> >> Hi Christian and all,
> >>
> >> On Thu, Aug 4, 2016 at 10:07 AM, Christian Stadler
wrote:
> >>> Am 01.08.2016 um 10:2
Of course calling e.g. strpos() should not trigger the auto-loader
repeatedly - can we cache the information that the auto-loader was
attempted once during the current script execution? so that e.g. only the
first call to strpos() triggers the auto-loader?
I suppose it would still happen once for
On Sun, Aug 7, 2016 at 1:19 PM, Rasmus Schultz wrote:
> I'd really like to see the function auto-loading proposal revived and/or
> possibly simplified.
>
> The fact that functions are hard (in some cases impossible) to reach by
> manually issuing require/include statements is, in my opinion, half
On 8/7/2016 1:19 PM, Rasmus Schultz wrote:
> I'd really like to see the function auto-loading proposal revived and/or
> possibly simplified.
>
+1 from my side for the revival. I would also love to see auto-loading
of namespaced constants like we have it for class constants.
--
Richard "Fleshgri
I'd really like to see the function auto-loading proposal revived and/or
possibly simplified.
The fact that functions are hard (in some cases impossible) to reach by
manually issuing require/include statements is, in my opinion, half the
difficulty, and a much more deeply rooted language problem e
Looks like it's unanimously a No.
Michael, don't be discouraged - I think that everyone agrees that there is
a problem to be solved, it's just that no one except you thinks this is a
good solution; many of us are of the opinion that it's not a solution that
really addresses the problem at all: you
Nikita,
Just to confirm for explicitness-sake:
> Nullable return types work inversely to void return types. You must
return either the specified type, or an explicit null. Anything else is
either a TypeError (incorrect type [implicitly] returned), or a [compile
time] fatal error (return without v
On Sun, Aug 7, 2016 at 9:07 AM, Davey Shafik wrote:
> Hi internals,
>
> In the nullable types we do not allow implicit return null/return with no
> value to fulfill a nullable type.
>
> - No return will result in a TypeError when executed
> - Return with no value will be an actual fatal error, wh
On Sun, Aug 7, 2016 at 1:07 AM, Davey Shafik wrote:
> Hi internals,
>
> In the nullable types we do not allow implicit return null/return with no
> value to fulfill a nullable type.
>
> - No return will result in a TypeError when executed
> - Return with no value will be an actual fatal error, wh
Hi internals,
In the nullable types we do not allow implicit return null/return with no
value to fulfill a nullable type.
- No return will result in a TypeError when executed
- Return with no value will be an actual fatal error, which I believe is
due to the fact it's not found at runtime, should
20 matches
Mail list logo
