Am 13.03.2015 um 11:30 schrieb Johannes Ott:
Am 13.03.2015 um 07:45 schrieb Crypto Compress:
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 g
Am 13.03.2015 um 09:57 schrieb Matteo Beccati:
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 ;)
Hello Matteo,
don't get your point. Are you against
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
On Fri, Mar 13, 2015 at 10:31 PM, Levi Morrison wrote:
> On Fri, Mar 13, 2015 at 8:50 PM, Rasmus Lerdorf wrote:
>> On Mar 14, 2015, at 13:37, Levi Morrison wrote:
>>> It seems that `float -> bool` is always disallowed. If I am correct
>>> `int -> bool` is permitted for all values (not just 0 and
On Fri, Mar 13, 2015 at 8:50 PM, Rasmus Lerdorf wrote:
> On Mar 14, 2015, at 13:37, Levi Morrison 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 int
On 14 March 2015 at 02:50, Rasmus Lerdorf 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 Internals - PH
On Mar 14, 2015, at 13:37, Levi Morrison 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 be boole
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 value
On Mar 13, 2015 10:36 PM, "Pierre Joye" 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 Pierre on this on
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
Hi
2015-03-13 6:02 GMT-03:00 Patrick ALLAERT :
> Le mer. 11 mars 2015 à 22:44, Marcio Almada a
> écrit :
>
>> 2015-03-11 6:27 GMT-03:00 Lester Caine :
>>
>> > On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote:
>>
>> > Most of the examples being shown are examples of simple bad program
> 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
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 announc
On Sat, 2015-03-14 at 00:22 +0100, Bob Weinand wrote:
> > Am 14.03.2015 um 00:14 schrieb Zeev Suraski :
> >
> >> -Original Message-
> >> From: Bob Weinand [mailto:bobw...@hotmail.com]
> >> Sent: Saturday, March 14, 2015 1:07 AM
> >> To: PHP Internals List
> >> Cc: Zeev Suraski; guilhermebl
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 developmen
> 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
Bob Weinand wrote on 14.03.2015 00:07:
>> Am 13.03.2015 um 23:03 schrieb Zeev Suraski :
>>
>> 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 ca
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,
including
> Am 14.03.2015 um 00:14 schrieb Zeev Suraski :
>
>> -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
>>
On Mar 14, 2015 10:14 AM, "Zeev Suraski" 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 Ty
> -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 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.
>
> I say
On Sat, Mar 14, 2015 at 12:02 AM, Arvids Godjuks
wrote:
> пт, 13 Мар 2015, 23:01, Philip Sturgeon :
>
> > Pavel,
> >
> > On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil
> wrote:
> > > On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara
> > wrote:
> > >>
> > >> But for today, I firmly believe that th
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 toget
> Am 13.03.2015 um 23:03 schrieb Zeev Suraski :
>
> 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 Strict c
пт, 13 Мар 2015, 23:01, Philip Sturgeon :
> Pavel,
>
> On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil wrote:
> > On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara
> wrote:
> >>
> >> But for today, I firmly believe that the Dual-Mode proposal is the
> >> only one that stands a chance of passing. I
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 rul
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 wrote:
> On Mar 14, 2015 9:24 AM, "Zeev Suraski" wrote:
> >
> > > -Original Message-
> > > From: stelian.
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 a
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 Mes
On Mar 14, 2015 9:24 AM, "Zeev Suraski" 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 E
> -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] [RF
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
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 wrote:
> Zeev, allow me to understand how this goes. Bob's discussions on the R
> -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
>
> Z
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 a
On Mar 14, 2015 9:03 AM, "Zeev Suraski" 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 yet
anot
> -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, 201
> -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 seriou
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 wrote:
>
> On Mar 14, 2015 7:50 AM, "Benjamin Eberlei" wrote:
> >
> > On Fri, Mar 13, 2015 at 9:44 PM, Zeev Suraski wrote:
> >
> >
On Mar 14, 2015 7:50 AM, "Benjamin Eberlei" wrote:
>
> On Fri, Mar 13, 2015 at 9:44 PM, Zeev Suraski wrote:
>
> > > -Original Message-
> > > From: Derick Rethans [mailto:der...@php.net]
> > > Sent: Friday, March 13, 2015 10:34 PM
> > > To: guilhermebla...@gmail.com; Stelian Mocanita
> > >
On Fri, Mar 13, 2015 at 4:44 PM, Zeev Suraski 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 Scalar
Hi,
2015-03-13 17:44 GMT-03:00 Zeev Suraski :
> > -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
On Fri, Mar 13, 2015 at 10:01 PM, Philip Sturgeon wrote:
> Pavel,
>
> On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil wrote:
>> On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara wrote:
>>>
>>> But for today, I firmly believe that the Dual-Mode proposal is the
>>> only one that stands a chance of pa
Pavel,
On Fri, Mar 13, 2015 at 3:38 PM, Pavel Kouřil wrote:
> On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara 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 t
On Fri, Mar 13, 2015 at 9:44 PM, Zeev Suraski 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
> -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
"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
>wrote:
>
>> So to get it clear for everyone: the right way is f
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 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
On Fri, Mar 13, 2015 at 4:45 PM, Anthony Ferrara 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 usages of PHP into a
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 mas
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 get
+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 wrote:
> 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 imple
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
eve
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
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
https://wiki.php.net/rfc/timing_safe_encoding
On 13 March 2015 at 17:24, Marcio Almada 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
> practical, we all kno
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 7:04 PM, Maciej Sobaczewski 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
> proces.
>
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 f
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
index
Am 13.03.2015 18:26 schrieb "Bostjan Skufca" :
>
> 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 doing.
T
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 w
Hi,
2015-03-13 12:45 GMT-03:00 Anthony Ferrara :
> 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 passing. So rath
Am 13.03.2015 18:18 schrieb "Jan Ehrhardt" :
>
> >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 box,
> Apa
For me PHP 5.5.20 works OK, but PHP 5.6.6 segfaults.
b.
On 13 March 2015 at 18:18, Jan Ehrhardt 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 the followi
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 \
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 evolut
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 yo
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 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 also t
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 way
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 discussed
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 uns
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 datas
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 alre
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'
/home/anon/gi
Le ven. 13 mars 2015 à 14:39, Lester Caine 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 *** while migr
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 users,
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
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, ye
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 s
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, Андрей Клюев
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 see a psychiatris
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 feat
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()
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 whe
Am 13.03.2015 um 07:45 schrieb Crypto Compress:
> 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 va
Hi Zeev,
On Thu, Mar 12, 2015 at 12:10 AM, Zeev Suraski 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 c
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 a
écrit :
> Hi Nikita,
>
> Le dim. 22 févr. 2015 à 23:31, Nikita Popov 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/
Hi Nikita,
Le dim. 22 févr. 2015 à 23:31, Nikita Popov 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 guidelines on when
Le mer. 11 mars 2015 à 22:44, Marcio Almada a
écrit :
> 2015-03-11 6:27 GMT-03:00 Lester Caine :
>
> > 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 fixing anyway, and I would exp
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 - P
Hey:
On Fri, Mar 13, 2015 at 3:50 PM, Dmitry Stogov 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 with CALL a
Hi all,
On Fri, Mar 13, 2015 at 2:17 PM, Andi Gutmans wrote:
> > On Mar 11, 2015, at 2:28 PM, Bob Weinand 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, I'd like to come up
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, 2
98 matches
Mail list logo
