Hi,
2015-03-13 12:45 GMT-03:00 Anthony Ferrara ircmax...@gmail.com:
All,
[...]
I respectfully ask Zeev to retract his current proposal as it's
currently failing with 68% of voters voting against it (currently
16:34). Without extending the timeline for 7, there's very little
chance of it
Am 13.03.2015 18:26 schrieb Bostjan Skufca bost...@a2o.si:
If we create unconditional php_server_context_cleanup() call at the
beginning of php_request(), would that be out of order? Does it remove also
all context-dependent configuration?
That's exactly what my Minipatch (addition of 1 ||) is
Johannes Ott wrote on 13/03/2015 15:35:
I think as Christoph wrote we should now do a cut here for the inital
discussion, because we are in a circle now. I will now get on at the RFC
process, and will prepare the RFC-draft asap.
I will try to summarize as good as possible all discussion points
Patrick Schaaf in php.internals (Tue, 10 Mar 2015 10:26:12 +0100):
Dear internals,
can somebody knowledgeable about the apache2handler code, please have a look
at the following bug report?
https://bugs.php.net/bug.php?id=68486
echo -e GET /test.php HTTP/1.1\nHost: localhost\n\n \
GET
Not that another +1 is needed, but I'm with Andi here. I do personally
like this 3rd proposal as an option, if nothing else because it
implements the 'simpler base' at the moment, and allows us, once people
are used to this being part of the language, to continue to evolve
later. And that
Maciej Sobaczewski in php.internals (Fri, 13 Mar 2015 19:04:30 +0100):
I think (and I do really hope) that some of those 33 votes came from
misunderstanding of the proposal.
Maybe. But on the other hand there are some names in the v0.5 no-camp,
that you would want to be on the yes side in such a
Bostjan Skufca in php.internals (Fri, 13 Mar 2015 18:20:55 +0100):
For me PHP 5.5.20 works OK, but PHP 5.6.6 segfaults.
OK (or rather not OK), I upgraded to 5.6.6:
echo -e GET /index.php HTTP/1.1\nHost: localhost\n\n \
GET /index.php HTTP/1.1\nHost: localhost\n\n|nc localhost 80
https://wiki.php.net/rfc/timing_safe_encoding
Hi internals,
I carefully read all 3 proposed RFCs related to scalar type hints.
As an end user and enthusiast of the language, I want PHP to always
improve. STH is *the* major inclusion for PHP 7 and no matter how many
people say about phpng performance, STH is the one that will impact mostly
+1 on this, as this is more inline with how ZPP currently works, creating
less headaches to end users.
On Fri, Mar 13, 2015 at 2:33 PM, Stelian Mocanita steli...@php.net wrote:
So to get it clear for everyone: the right way is for internals to ignore
community as a
whole, stick to their own
Eli, I don't even try to. However, when the result is tentative, it's
good to be sure that we don't have any incorrect votes.
Yes, I'm in favor of this RFC and I never concealed it, *but* I'm not
going to discredit any of the voting members. If the final decision will
be negative I'll just
For me PHP 5.5.20 works OK, but PHP 5.6.6 segfaults.
b.
On 13 March 2015 at 18:18, Jan Ehrhardt php...@ehrhardt.nl wrote:
Patrick Schaaf in php.internals (Tue, 10 Mar 2015 10:26:12 +0100):
Dear internals,
can somebody knowledgeable about the apache2handler code, please have a
look
at
On Fri, Mar 13, 2015 at 7:04 PM, Maciej Sobaczewski so...@php.net wrote:
Currently Scalar Type Declarations are going to fall. We have 33 No votes
and I really wonder why there is almost no justification for them. I know
that it's not required, but it is a matter of good taste in whole voting
On 13 March 2015 at 17:24, Marcio Almada marcio.w...@gmail.com wrote:
At the time I'm witting this, the Coercive Scalar Types RFC needs 52
yes votes to reach minimum ratio. This RFC was well discussed and people
justified their no votes quite verbosely on the respective thread. Being
Currently Scalar Type Declarations are going to fall. We have 33 No
votes and I really wonder why there is almost no justification for them.
I know that it's not required, but it is a matter of good taste in whole
voting proces.
I think (and I do really hope) that some of those 33 votes came
Am 13.03.2015 18:18 schrieb Jan Ehrhardt php...@ehrhardt.nl:
https://bugs.php.net/bug.php?id=68486
echo -e GET /test.php HTTP/1.1\nHost: localhost\n\n \
GET /test.php HTTP/1.1\nHost: localhost\n\n|nc localhost 80
Are you running opcache? I tried to reproduce the bug on a Centos6
So to get it clear for everyone: the right way is for internals to ignore
community as a
whole, stick to their own views and implement something nobody actually
wants - just
because there is no time - on the idea that something is better than
nothing?
Without pointing any fingers it sure looks
I really don't think that you want us to be going down the
Republican/Democrat Redistricting game Maciej, not during an active
vote at least. Attempting to 'help one side win' by deciding that some
people's votes on the side that you are not for ... should just be
discounted.
Is not the way to
On Fri, Mar 13, 2015 at 10:01 PM, Philip Sturgeon pjsturg...@gmail.com wrote:
Pavel,
On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara ircmax...@gmail.com wrote:
But for today, I firmly believe that the Dual-Mode proposal
Pavel_Kouřil wrote:
- It is a setting that changes the language's behavior; I don't
think that it matters whether or not it would be an INI setting or the
declare() one, because both of them are bad.
It allows people who want strict typing to declare it on a per-PHP-file
basis. An INI
On Fri, Mar 13, 2015 at 4:44 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Derick Rethans [mailto:der...@php.net]
Sent: Friday, March 13, 2015 10:34 PM
To: guilhermebla...@gmail.com; Stelian Mocanita
Cc: Eli; PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Basic
On Mar 14, 2015 7:50 AM, Benjamin Eberlei kont...@beberlei.de wrote:
On Fri, Mar 13, 2015 at 9:44 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Derick Rethans [mailto:der...@php.net]
Sent: Friday, March 13, 2015 10:34 PM
To: guilhermebla...@gmail.com;
On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara ircmax...@gmail.com wrote:
But for today, I firmly believe that the Dual-Mode proposal is the
only one that stands a chance of passing. I think it's the best chance
for the language, and it's the only one that tries to unite the
different
guilhermebla...@gmail.com guilhermebla...@gmail.com schreef op 13 maart
2015 18:57:35 GMT+00:00:
+1 on this, as this is more inline with how ZPP currently works,
creating
less headaches to end users.
On Fri, Mar 13, 2015 at 2:33 PM, Stelian Mocanita steli...@php.net
wrote:
So to get it clear
Hi,
2015-03-13 17:44 GMT-03:00 Zeev Suraski z...@zend.com:
-Original Message-
From: Derick Rethans [mailto:der...@php.net]
Sent: Friday, March 13, 2015 10:34 PM
To: guilhermebla...@gmail.com; Stelian Mocanita
Cc: Eli; PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Basic
I really want to understand if we're gonna allow this RFC voting or not.
That's important to reconsider my vote on STH
On Fri, Mar 13, 2015 at 5:36 PM, Pierre Joye pierre@gmail.com wrote:
On Mar 14, 2015 7:50 AM, Benjamin Eberlei kont...@beberlei.de wrote:
On Fri, Mar 13, 2015 at 9:44
A two week discussion period has been held and there are no outstanding issues.
Serialization has been disabled, and generated names have been
explained better in the newest version of the RFC
https://wiki.php.net/rfc/anonymous_classes
The implementation needs to be updated with changes from
-Original Message-
From: Philip Sturgeon [mailto:pjsturg...@gmail.com]
Sent: Friday, March 13, 2015 11:16 PM
To: Zeev Suraski
Cc: Derick Rethans; Eli; guilhermebla...@gmail.com; Stelian Mocanita; PHP
Internals List
Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types
But seriously
On Mar 14, 2015 9:03 AM, Zeev Suraski z...@zend.com wrote:
Maybe I was naïve, but I thought I had a better way to make both weak
strict camps happy,
By dropping strict despite all discussions, proposing a pandara box rfc by
changing the casting rules and now suddenly proposing to go vote to
On Fri, Mar 13, 2015 at 9:44 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Derick Rethans [mailto:der...@php.net]
Sent: Friday, March 13, 2015 10:34 PM
To: guilhermebla...@gmail.com; Stelian Mocanita
Cc: Eli; PHP Internals List
Subject: Re: [PHP-DEV] [RFC]
-Original Message-
From: Benjamin Eberlei [mailto:kont...@beberlei.de]
Sent: Friday, March 13, 2015 10:50 PM
To: Zeev Suraski
Cc: Derick Rethans; Eli; Guilherme Blanco; Stelian Mocanita; PHP Internals
List
Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types
On Fri, Mar 13, 2015 at
-Original Message-
From: Derick Rethans [mailto:der...@php.net]
Sent: Friday, March 13, 2015 10:34 PM
To: guilhermebla...@gmail.com; Stelian Mocanita
Cc: Eli; PHP Internals List
Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types
Chance of this RFC passing is going to be slim, as it
Zeev, allow me to understand how this goes. Bob's discussions on the RFC
started 2 days ago. Based on the current rules, the RFC can only go to vote
after 2 weeks. That means in 12 days starting now.
So we are either violating the RFC rules by pushing the vote tomorrow or
we're
delaying PHP7 for
So sticking to the rules is now playing law firm. The RFC Andreea
proposed has
been modified several times before going to vote. And we're not voting on
her RFC,
we're voting on Bob's that was proposed 2 days ago.
I have a feeling that this will go to vote tomorrow though.
On Fri, Mar 13, 2015
I'll switch my vote on STH v5 to YES.
If we get Basic STH into voting phase, I change my vote to NO and vote on
YES on Basic STH.
[]s,
On Fri, Mar 13, 2015 at 6:35 PM, Pierre Joye pierre@gmail.com wrote:
On Mar 14, 2015 9:24 AM, Zeev Suraski z...@zend.com wrote:
-Original
пт, 13 Мар 2015, 23:01, Philip Sturgeon pjsturg...@gmail.com:
Pavel,
On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
But for today, I firmly believe that the Dual-Mode proposal is the
-Original Message-
From: Bob Weinand [mailto:bobw...@hotmail.com]
Sent: Saturday, March 14, 2015 1:07 AM
To: PHP Internals List
Cc: Zeev Suraski; guilhermebla...@gmail.com
Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types
Am 13.03.2015 um 23:03 schrieb Zeev Suraski
Hi all,
On 13 March 2015 at 22:51, Pierre Joye pierre@gmail.com wrote:
On Mar 14, 2015 9:47 AM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
I'll switch my vote on STH v5 to YES.
If we get Basic STH into voting phase, I change my vote to NO and vote on
YES on Basic STH.
On Mar 14, 2015 10:14 AM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Bob Weinand [mailto:bobw...@hotmail.com]
Sent: Saturday, March 14, 2015 1:07 AM
To: PHP Internals List
Cc: Zeev Suraski; guilhermebla...@gmail.com
Subject: Re: [PHP-DEV] [RFC] Basic Scalar
Opcode caches just cache the compiled code - you still need to load the
code into the engine, do checks for file modifications and other stuff.
Yes, if you are a badass and have full controll, all that can be solved.
Reality, however, is one big f***up. I had to fix a lot of weird stuff,
And actually, I would plea for a moment of sanity right now.
As far as i'm concerned - the RM for the 7.0 had to step in a long time ago
and said guys, I do not accept any typehint proposals into the 7.0
release, work it out and come back for 7.1.
Because if this would be a commercial development
On 13/03/15 18:53, guilhermebla...@gmail.com wrote:
By considering PHP's nature, having a dual mode is a WTF. I can see myself
asking multiple times a day is this file strict or not? to trace
potential bugs or type juggling. I do want strict, but I don't think it's
the right time for PHP to
Pavel,
On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara ircmax...@gmail.com wrote:
But for today, I firmly believe that the Dual-Mode proposal is the
only one that stands a chance of passing. I think it's the best chance
On Mar 13, 2015 10:36 PM, Pierre Joye pierre@gmail.com wrote:
So law is firm when it fits your goal but flexible when not? We have
relatively strict rules for this exact reason: nk double standard. Stop
playing with the rules and stand as someone willing to find compromises.
Totally with
Zeev, Dmitry and Francois (and anyone),
I have a question on a specific conversion. There has been *a lot* of
email about scalar types so I apologize if this is answered somewhere
already.
It seems that `float - bool` is always disallowed. If I am correct
`int - bool` is permitted for all values
On Mar 14, 2015, at 13:37, Levi Morrison le...@php.net wrote:
It seems that `float - bool` is always disallowed. If I am correct
`int - bool` is permitted for all values (not just 0 and 1), which
means that floats which can be converted to integers without dataloss
should also be permitted to
On 14 March 2015 at 02:50, Rasmus Lerdorf ras...@lerdorf.com wrote:
The problem there is what does without dataloss mean? At which precision do
you consider there to be no dataloss?
-Rasmus
without dataloss would mean you can go from typeA - typeB - typeA'
and typeA === typeA'
--
PHP
On Fri, Mar 13, 2015 at 10:31 PM, Levi Morrison le...@php.net wrote:
On Fri, Mar 13, 2015 at 8:50 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On Mar 14, 2015, at 13:37, Levi Morrison le...@php.net wrote:
It seems that `float - bool` is always disallowed. If I am correct
`int - bool` is
On Fri, Mar 13, 2015 at 8:50 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On Mar 14, 2015, at 13:37, Levi Morrison le...@php.net wrote:
It seems that `float - bool` is always disallowed. If I am correct
`int - bool` is permitted for all values (not just 0 and 1), which
means that floats which
RFC Link: https://wiki.php.net/rfc/reserve_more_types_in_php_7
The proposal has changed from the original. It no longer reserves the
aliases out of the interest of reserving the smallest useful,
uncontroversial subset. Some people want to remove aliases for these
types so in the interest of being
Arvids,
That declare thing with the removal of block-aware declare(){} kills one of
the fundamental optimizations you can do for large PHP projects - compacting
most used files into one single big file and caching it. And you never had
to care what the files are - just splice it all together
On Sat, Mar 14, 2015 at 12:02 AM, Arvids Godjuks arvids.godj...@gmail.com
wrote:
пт, 13 Мар 2015, 23:01, Philip Sturgeon pjsturg...@gmail.com:
Pavel,
On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil pajou...@gmail.com
wrote:
On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara
On Fri, 13 Mar 2015, guilhermebla...@gmail.com wrote:
I really want to understand if we're gonna allow this RFC voting or not.
That's important to reconsider my vote on STH
Well, if we look at it the theoretical way, then no, we won't be able
to consider this one for PHP 7:
- It got
On Sat, 2015-03-14 at 00:22 +0100, Bob Weinand wrote:
Am 14.03.2015 um 00:14 schrieb Zeev Suraski z...@zend.com:
-Original Message-
From: Bob Weinand [mailto:bobw...@hotmail.com]
Sent: Saturday, March 14, 2015 1:07 AM
To: PHP Internals List
Cc: Zeev Suraski;
On 3/13/15 6:26 PM, guilhermebla...@gmail.com wrote:
And none answered me... is this RFC gonna be allowed to enter on voting
phase for 7.0 or not?
This drastically changes my voted on STH v5 which ends EOD today.
Actually it doesn't Guilherme. If you look at the STH v5 it states:
will
-Original Message-
From: stelian.mocan...@gmail.com [mailto:stelian.mocan...@gmail.com]
On Behalf Of Stelian Mocanita
Sent: Saturday, March 14, 2015 12:18 AM
To: Pierre Joye
Cc: Zeev Suraski; PHP internals; Benjamin Eberlei
Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types
Zeev,
And none answered me... is this RFC gonna be allowed to enter on voting
phase for 7.0 or not?
This drastically changes my voted on STH v5 which ends EOD today.
[]s,
On Fri, Mar 13, 2015 at 6:17 PM, Stelian Mocanita steli...@php.net wrote:
Zeev, allow me to understand how this goes. Bob's
Guilherme,
The v0.5 RFC vote is NOT ending today, but rather on EOD of the 25th.
Anthony put in the text saying that the vote will end no sooner than when
the vote for the competing RFC will end, and that's March 25th.
I hope we do get a chance to vote on the Basic RFC.
Zeev
-Original
On 01/03/2015 02:11, Marcio Almada wrote:
the voting for the Context
Sensitive Lexer is now open.
Hi,
After discussing this with other members of AFUP (well, not any of the
implementations, as we don't really have the expertise needed for that
-- but the feature as seen by end-users), we
Hi
2015-03-13 6:02 GMT-03:00 Patrick ALLAERT patrickalla...@php.net:
Le mer. 11 mars 2015 à 22:44, Marcio Almada marcio.w...@gmail.com a
écrit :
2015-03-11 6:27 GMT-03:00 Lester Caine les...@lsces.co.uk:
On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote:
Most of the examples
Bob Weinand wrote on 14.03.2015 00:07:
Am 13.03.2015 um 23:03 schrieb Zeev Suraski z...@zend.com:
Maybe I was naïve, but I thought I had a better way to make both weak
strict camps happy, instead of just ignoring the strict camp altogether.
While there was some opposition to it - it mostly
This whole thing is depressing. I am confident Zeev means well, but as a
usually silent watcher of this list, I'll give this bystander's view of
the recent
discussion:
I don't like X, but I'll vote for it unless I can get Y approved.
I can't get Y approved, but I don't want to vote for X;
On Mar 14, 2015 9:24 AM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: stelian.mocan...@gmail.com [mailto:stelian.mocan...@gmail.com]
On Behalf Of Stelian Mocanita
Sent: Saturday, March 14, 2015 12:18 AM
To: Pierre Joye
Cc: Zeev Suraski; PHP internals; Benjamin
-Original Message-
From: stelian.mocan...@gmail.com [mailto:stelian.mocan...@gmail.com]
On Behalf Of Stelian Mocanita
Sent: Saturday, March 14, 2015 12:30 AM
To: guilhermebla...@gmail.com
Cc: Pierre Joye; Zeev Suraski; PHP internals; Benjamin Eberlei
Subject: Re: [PHP-DEV] [RFC]
On Mar 14, 2015 9:47 AM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
I'll switch my vote on STH v5 to YES.
If we get Basic STH into voting phase, I change my vote to NO and vote on
YES on Basic STH.
I say it again: it should not be accepted. Or we can just scratch our rules
and
Am 13.03.2015 um 23:03 schrieb Zeev Suraski z...@zend.com:
Maybe I was naïve, but I thought I had a better way to make both weak
strict camps happy, instead of just ignoring the strict camp altogether.
While there was some opposition to it - it mostly came from the main
proponents of the
Am 14.03.2015 um 00:14 schrieb Zeev Suraski z...@zend.com:
-Original Message-
From: Bob Weinand [mailto:bobw...@hotmail.com]
Sent: Saturday, March 14, 2015 1:07 AM
To: PHP Internals List
Cc: Zeev Suraski; guilhermebla...@gmail.com
Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types
Zeev,
If I put it into vote until Sunday, we're breaking the voting process.
Which
required an apt discussion phase which definitely isn't given when we
start
Sunday.
Bob,
I do see it differently but obviously very much respect your position.
Why do I see it differently? The mandatory two
Hello Johannes,
in other mails you argue with Rowan about global state. I think it's
better to focus on innovation of class context in global scope, as
it's impossible to reason the disadvantages of global state away.
(Discussions on variable scope are painful too.)
And two questions:
1. By
Am 12.03.2015 um 20:42 schrieb Thomas Punt:
The only compromise I can think of (though not sure on its feasibility) would be
to have a flag as the last parameter that defaulted to logically AND'ing its
args
with the ability to switch the semantics to logically OR the args.
Hello Thomas,
how
Hi Xinchen,
I don't like to remove anything. I think GOTO may be made faster. It's just
not very interesting to invest into it, because CALL is more suitable.
execute_data-opline-handler(execute_data); won't work with CALL and
global CPU registers s well :(
Thanks. Dmitry.
On Fri, Mar 13,
On 13/03/2015 07:46, Crypto Compress wrote:
how about two separate methods all_empty() and non[e]_empty()?
How about empty() and full() ?
Ok, that was a bad attempt as a joke, but please no ;)
Cheers
--
Matteo Beccati
Development Consulting - http://www.beccati.com/
--
PHP Internals -
Hi Nikita,
Le dim. 22 févr. 2015 à 23:31, Nikita Popov nikita@gmail.com a écrit :
Hi internals!
I would like to propose reclassifying our few existing E_STRICT notices and
removing this error category:
https://wiki.php.net/rfc/reclassify_e_strict
As we don't really have good
Hi Zeev,
On Thu, Mar 12, 2015 at 12:10 AM, Zeev Suraski z...@zend.com wrote:
The latest version of the RFC includes changes discussed on internals@
last
week:
1. Accept string-bool and int-bool conversions (false-bool is not
supported)
2. Accept leading/trailing spaces in string-number
Hi all,
On Fri, Mar 13, 2015 at 2:17 PM, Andi Gutmans a...@zend.com wrote:
On Mar 11, 2015, at 2:28 PM, Bob Weinand bobw...@hotmail.com wrote:
Hi all,
after all, some people are not happy with the current proposals about
scalar types. So, they both still possibly may fail.
Thus,
Le mer. 11 mars 2015 à 22:44, Marcio Almada marcio.w...@gmail.com a
écrit :
2015-03-11 6:27 GMT-03:00 Lester Caine les...@lsces.co.uk:
On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote:
Most of the examples being shown are examples of simple bad programming
practice that needs
Hey:
On Fri, Mar 13, 2015 at 3:50 PM, Dmitry Stogov dmi...@zend.com wrote:
Hi Xinchen,
I don't like to remove anything. I think GOTO may be made faster. It's just
not very interesting to invest into it, because CALL is more suitable.
execute_data-opline-handler(execute_data); won't work
Am 13.03.2015 um 01:33 schrieb Christoph Becker:
Johannes Ott wrote:
And i although see no DI or Singleton pattern to use here to get the
same functionality, if you want to use like Config::getHostname() and
not like Config::getInstance()-getHostname() which is really
unnecessary
Le ven. 13 mars 2015 à 10:33, Patrick ALLAERT patrickalla...@php.net a
écrit :
Hi Nikita,
Le dim. 22 févr. 2015 à 23:31, Nikita Popov nikita@gmail.com a
écrit :
Hi internals!
I would like to propose reclassifying our few existing E_STRICT notices
and
removing this error category:
Johannes Ott wrote on 12/03/2015 23:36:
Am 12.03.2015 um 21:33 schrieb Rowan Collins:
Johannes Ott wrote on 12/03/2015 19:45:
All of the magic methods are doing like this.
I thought you might say that, but the only thing remotely similar I can
think of is a destructor, which gets called
Hello internals! My name is Andrew and I write php literally since
childhood (something around 10 years),
now PHP - is my profession.
And today once again debugging foreign code, I was ready to go to the
hospital to see a psychiatrist.
First, some of the code:
Do you think that can output this
Oh! Thanks Nikita. I did not know that the exceptions in the engine already
accepted. But in fairness, in PHP A $a typehint does not make sure that
$a instanceof A returns true. You can change test fucntion in code
form my first message to
function test(A $a)
{
var_dump($a instanceof A);
}
On Fri, Mar 13, 2015 at 12:48 PM, Андрей Клюев kluev.and...@gmail.com
wrote:
Hello internals! My name is Andrew and I write php literally since
childhood (something around 10 years),
now PHP - is my profession.
And today once again debugging foreign code, I was ready to go to the
hospital to
On Tuesday 10 March 2015 10:26:12 Patrick Schaaf wrote:
https://bugs.php.net/bug.php?id=68486
Meanwhile I did some more debugging, today also testing with a freshly
compiled current apache 2.4.12. The issue persists.
As it does not always coredump, but always uncontrollably reenters an
Any resolution suggestions for this error when running make
after ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql:
ext/standard/.libs/info.o: In function `php_print_gpcse_array':
/home/anon/git/php-src/ext/standard/info.c:207: undefined reference to
`_tsrm_ls_cache'
Johannes Ott wrote on 13/03/2015 09:53:
Am 13.03.2015 um 01:33 schrieb Christoph Becker:
Johannes Ott wrote:
And i although see no DI or Singleton pattern to use here to get the
same functionality, if you want to use like Config::getHostname() and
not like Config::getInstance()-getHostname()
Am 13.03.2015 um 14:36 schrieb Rowan Collins:
Sorry, replying to myself to add a couple of thoughts / clarifications:
Rowan Collins wrote on 13/03/2015 11:53:
Johannes Ott wrote on 13/03/2015 09:53:
Why are in your opinion static members are not allowed to hold more
complexe datastructures
Hi there,
as you can see at the initial discussion thread with the subject static
constructor I'm planing to do a Draft for a RFC for the suggested feature.
How do I get the karma to create this RFC on wiki?
Regards,
--
DerOetzi
--
PHP Internals - PHP Runtime Development Mailing List
To
All,
There's something that I think needs to be said about the now 3 scalar
type proposals. Please bear with me, there's a lot to say here. I'll
try to keep it as brief as I can.
I've been working off-and-on on scalar types for over 3 years. I've
officially proposed 3 proposals and have
Sorry for hype.
If found this text in Engine Exceptions RFC just now
`The E_RECOVERABLE_ERROR part of the proposal may introduce a minor BC
break, because it will no longer allow to silently ignore recoverable
errors with a custom error handler. As this point is somewhat controversial
I'll have a
Sorry, replying to myself to add a couple of thoughts / clarifications:
Rowan Collins wrote on 13/03/2015 11:53:
Johannes Ott wrote on 13/03/2015 09:53:
Why are in your opinion static members are not allowed to hold more
complexe datastructures then simple scalars?
Complex data structures,
Hi Internals,
This email is to inform you that Olivier and I have opened for discussion a
new RFC in order, for PHP extensions authors, to hook more easily into the
default error handler callback:
https://wiki.php.net/rfc/improved_error_callback_mechanism
There is zero new feature for the
On 13/03/15 09:02, Patrick ALLAERT wrote:
It also depends on your perception of E_STRICT. This level has been
introduced in 5.0 without being part of E_ALL in order to, among other
things, avoid too much pain in the *** while migrating from 4.x to 5.x.
As of 5.4, E_ALL contains E_STRICT and
Le ven. 13 mars 2015 à 14:39, Lester Caine les...@lsces.co.uk a écrit :
On 13/03/15 09:02, Patrick ALLAERT wrote:
It also depends on your perception of E_STRICT. This level has been
introduced in 5.0 without being part of E_ALL in order to, among other
things, avoid too much pain in the
Thanks for the clear statement, which lights up the fog a little bit for.
Watching out for a scalar typehints feature for round about 10 years
without knowing about this internal list, I always was wondering what
can be so complicated to implement it, because I already evaluated some
different
I can confirm the behaviour. Even if I do not change script names and/or
HTTP host.
b.
On 13 March 2015 at 16:01, Patrick Schaaf p...@bof.de wrote:
On Tuesday 10 March 2015 10:26:12 Patrick Schaaf wrote:
https://bugs.php.net/bug.php?id=68486
Meanwhile I did some more debugging, today
Thanks Anthony for the thorough explanation and your view on the matter,
highly appreciated. I am sure that long-term developers have gone through
both ends of the strong types, either loving their lack while picking up
php for
the first time, either cursing it's lack later on along the way.
As
97 matches
Mail list logo
