Am 22.03.2015 02:30 schrieb "Leigh" :
>
> Yep, this does look like another case of simply ignoring rules. The fact
> that what does and does not require an RFC does not help, this probably
> didn't need one, however one was created and the rules need to be stuck
to.
Hmm. Is that really the line to
On Mar 22, 2015 2:01 PM, "Patrick Schaaf" wrote:
>
> Am 22.03.2015 02:30 schrieb "Leigh" :
> >
> > Yep, this does look like another case of simply ignoring rules. The fact
> > that what does and does not require an RFC does not help, this probably
> > didn't need one, however one was created and t
On Sun, Mar 22, 2015 at 2:38 AM, Leigh wrote:
> Hi all,
>
> With 7.0 feature freeze in effect, and proposals and RFCs still coming in
> that are going to target 7.1, I think it's time we branched master and
> selected a release manager (or two) for 7.0.
>
> Traditionally the newer RM from the pre
On Sun, Mar 22, 2015 at 2:32 PM, Ferenc Kovacs wrote:
> On Sun, Mar 22, 2015 at 2:38 AM, Leigh wrote:
>
>> Hi all,
>>
>> With 7.0 feature freeze in effect, and proposals and RFCs still coming in
>> that are going to target 7.1, I think it's time we branched master and
>> selected a release manage
On 22 March 2015 at 07:49, Pierre Joye wrote:
>
> From A RM point of view, I agree with other here, I could not think of
> a better person than you as one of the RMs. You did and still do a
> fantastic job, keeping things up and running, awesome communications,
> etc. As a 2nd RM, I would like som
On 22 March 2015 at 07:00, Patrick Schaaf wrote:
>
> Hmm. Is that really the line to be drawn? An RFC, by itself, provides a
> good point to spell out a change clearly, and anchor it for reference in
> discussion. Discussion on internals itself cannot provide that, it is too
> scattered, and POC c
Am 22.03.2015 09:45 schrieb "Leigh" :
>
> On 22 March 2015 at 07:00, Patrick Schaaf wrote:
>>
>> Hmm. Is that really the line to be drawn? An RFC, by itself, provides a
good point to spell out a change clearly, and anchor it for reference in
discussion. Discussion on internals itself cannot provid
On 21 March 2015 at 12:13, Georges.L wrote:
> Hi php internals,
>
> After some long and deep research i finally decided to write my first RFC
> about a feature i'd be interested to be improved in the php core: *Nested
> enclosing returns*
>
>
> The main purpose, as the title say, is to have the p
On 22 March 2015 at 08:54, Patrick Schaaf wrote:
>
> Okay, that's easier to implement and probably sufficient, if everybody
> play nice. Or, another idea and maybe a lot less work to implement: all
> active release managers could have a "want a vote" button on pending RFC
> pages.
>
+1 on RM sign
On Mar 22, 2015 3:45 PM, "Leigh" wrote:
>
> On 22 March 2015 at 07:00, Patrick Schaaf wrote:
> >
> > Hmm. Is that really the line to be drawn? An RFC, by itself, provides a
> > good point to spell out a change clearly, and anchor it for reference in
> > discussion. Discussion on internals itself
Am 21.03.2015 14:15 schrieb "Georges.L" :
>
> The main purpose, as the title say, is to have the possibility to nest
> multiple return like we can do currently with break/continue.
I think that is a complete nonstarter. Functions are reusable building
blocks, designed to be called from various pla
On 21 March 2015 17:55:32 GMT, "Georges.L" wrote:
>To be honest I had not thought about the bad side of this use, i guess
>it
>could be possible to not return upper than a try/catch block (then
>return a
>fatal error if our code is trying to returns upper than a try/catch
>block).
>
>Now the pract
On 22/03/15 08:54, Patrick Schaaf wrote:
>> Sure, I can agree on RFC all the things.
> Probably not all things, but surely everything visible at the language
> level, that would need documentation. Syntax, functions, function argument
> changes. Probably also changes of official C level API for mod
On 22/03/15 01:38, Leigh wrote:
> With 7.0 feature freeze in effect, and proposals and RFCs still coming in
> that are going to target 7.1, I think it's time we branched master and
> selected a release manager (or two) for 7.0.
Is there any need to allow commits to master which are targeted beyond
OK. It was just a suggestion. Forget it. Thanks for your time.
> -Message d'origine-
> De : Netroby [mailto:hufeng1...@gmail.com]
> Envoyé : dimanche 22 mars 2015 01:21
> À : Benoit Schildknecht
> Cc : PHP Internals
> Objet : Re: [PHP-DEV] Proposal to delay 7.0 timeline
>
> Please do not
>De : Nathan wesley [mailto:nathan.o.wes...@gmail.com]
>
> if you're going to write API for string manipulation for example you want it
> either Object Oriented or procedural style.
> because the API should be fluent method chaining etc. you don't want to stop
> the chain and wrap it with a fu
Hi,
I am sorry if I am wrong but why it is not people that started php 7/ng
project ? Dmitry, Nikita or Xichen ?
On 22 March 2015 at 13:33, Yannick Komotir wrote:
> Hi,
>
> I am sorry if I am wrong but why it is not people that started php 7/ng
> project ? Dmitry, Nikita or Xichen ?
>
Personal opinion: I'd prefer all of these people had more time to work on
code, and didn't have to worry about RM duties :)
2015.03.22. 14:33 ezt írta ("Yannick Komotir" ):
>
> Hi,
>
> I am sorry if I am wrong but why it is not people that started php 7/ng
> project ? Dmitry, Nikita or Xichen ?
I'm fairly sure any of those three would have overwhelming support for
RMing if they would decide to volunteer.
(Personally I
> So, we need features. We already have
> STH, but we can do more (I personally have at least 4 RFCs I didn’t have
> time for, including scalar pseudo-methods, which can be an important
> feature).
We add scalar and return types in PHP 7.0. We also add null coalesce
`??` and three-way comparison o
Hi Nathan,
On Sat, Mar 21, 2015 at 1:01 PM, Nathan wesley
wrote:
> I know that many people talked about this over and over.
>
> Why it’s not possible to change the old PHP API ?
>
> The answer is always because it will make HUGE BC breaks
>
> I’ve seen this wonderful idea about scalar object
Hi!
> This makes an opportunity to replace the old API with object oriented one
> preventing any kind of BC break.
>
> But instead of using this as an extension because of some limitations like
> “string”->startsWith(‘s’); the API should be bundled with the engine (not
> written in PHP).
This is
On Mon, Mar 16, 2015 at 9:20 AM, Leigh wrote:
>
> On 16 March 2015 at 04:58, Levi Morrison wrote:
>>
>> Dear Internals,
>>
>> I am tentatively opening the vote on this RFC:
>> https://wiki.php.net/rfc/reserve_more_types_in_php_7
>>
>> It's a bit tentative because I would prefer to wait until the
Hi!
Looking into some issue, I've discovered that, to my surprise,
Exceptions are serializable. Except that it doesn't always work of
course (e.g. see http://stackoverflow.com/q/9747813/214196) because
exceptions contain backtraces, and those can contain non-serializable
objects. So in reality, yo
Maybe you can implement the __sleep method and just return the documented
attributes (message, code, file, line).
Not perfect, but probably more useful than throw an exception, specially if
the exception is something that is the attribute of some object that is
being serialized.
Juan Basso
On Mar
On Mon, Mar 23, 2015 at 12:31 PM, Juan Basso wrote:
> Maybe you can implement the __sleep method and just return the documented
> attributes (message, code, file, line).
>
> Not perfect, but probably more useful than throw an exception, specially if
> the exception is something that is the attribu
> -Ursprüngliche Nachricht-
> Von: Pierre Joye [mailto:pierre@gmail.com]
> Gesendet: Montag, 23. März 2015 06:57
> An: Juan Basso
> Cc: Stanislav Malyshev; PHP Internals
> Betreff: Re: [PHP-DEV] Serializing exceptions
>
> On Mon, Mar 23, 2015 at 12:31 PM, Juan Basso wrote:
> > Maybe
Hi,
Am 23.03.2015 um 06:21 schrieb Stanislav Malyshev:
> Looking into some issue, I've discovered that, to my surprise,
> Exceptions are serializable. Except that it doesn't always work of
> course (e.g. see http://stackoverflow.com/q/9747813/214196) because
> exceptions contain backtraces, and th
Hi!
> I think we should discuss if (un)serialization is a first-class
> operation in the language and if so, we should try to make everything
> serializable. Currently, we introduce more and more unserializable
I don't think we can, not unless we can serialize PHP code (like Java
can have JARs wi
Hi!
> Maybe you can implement the __sleep method and just return the
> documented attributes (message, code, file, line).
That would be an option, but before going there, my question is - does
anybody need it, really?
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Developm
30 matches
Mail list logo
