Hi David,
On Tue, Jul 22, 2014 at 2:42 PM, David Soria Parra wrote:
> >
> > Even if we have PHP-5.7 branch, we have merge up policy. Therefore,
> > any new feature will end up with master, I suppose. If a new feature is
> > only available to PHP-5.7 branch, it's a merge bug, isn't it?
> >
> > Re
On 22/07/14 03:58, Pierre Joye wrote:
> Now, as I already suggested many times (but with zero reply from
> Zend's), let step back, get our roadmap setup, todos, goals, agreement
> and get back to work. But a forcing move to php-next within a year
> with almost only phpng is a major mistake and will
On 22/07/14 07:44, Dmitry Stogov wrote:
> Big PHP users just can't not to care about performance, because it's money.
> I know most of them already experimented with HHVM.
Big users don't use PHP ...
> If we don't provide adequate replay, we may turn back into the language for
> home pages.
Is tha
On Tue, Jul 22, 2014 at 11:11 AM, Lester Caine wrote:
> On 22/07/14 07:44, Dmitry Stogov wrote:
> > Big PHP users just can't not to care about performance, because it's
> money.
> > I know most of them already experimented with HHVM.
> Big users don't use PHP ...
>
You are wrong :)
Thanks. Dmit
Hi Anthony,
I noticed I've made silly mistakes in previous reply. I've added little
more.
Even if I remove text formatting, gmail insists strange formatting. It may
be hard to read...
Please disregard old one and read this.
On Mon, Jul 21, 2014 at 11:32 PM, Anthony Ferrara
wrote:
>
> > E_NOTICE
> -Original Message-
> From: Lester Caine [mailto:les...@lsces.co.uk]
> Sent: Tuesday, July 22, 2014 10:12 AM
> To: PHP internals
> Subject: Re: [PHP-DEV] RFC: Move phpng to master
>
> Big users don't use PHP ...
Just to elaborate (slightly) on Dmitry's answer - this is an absolutely
wron
hi,
On Tue, Jul 22, 2014 at 9:52 AM, Zeev Suraski wrote:
> I stand by my statement that I'm
> sure a great deal of users (my guesstimate - the majority) would happily
> upgrade to PHP.NEXT even if the huge performance gains were the only thing
> there.
I fully agree with you about breakages.
On Tue, Jul 22, 2014 at 10:45 AM, Pierre Joye wrote:
> hi,
>
> On Tue, Jul 22, 2014 at 9:52 AM, Zeev Suraski wrote:
>
> > I stand by my statement that I'm
> > sure a great deal of users (my guesstimate - the majority) would happily
> > upgrade to PHP.NEXT even if the huge performance gains wer
On Tue, Jul 22, 2014 at 11:18 AM, Benjamin Eberlei wrote:
> This is the opportunity to do the cleanup now, based on phpng branch. Since
> the branch is pulic on Github, how is development secret?
Benjamin, please check the background before replying. 80% of phpng
development has been done secret
On 22/07/14 10:32, Pierre Joye wrote:
>> As i understood Nikita and laurence they are already improving it based on
>> > the first prototype from month ago. Honestly, if Nikita says converting his
>> > extensions improved the API a lot then this is a good sign for me already.
> It does not improve
On Tue, Jul 22, 2014 at 3:42 AM, Xinchen Hui wrote:
> Hey:
>
> I really don't like arguing in english, so this will be my last
> reply in this thread.
>
sorry to bother you, and my "backlash" wasn't really targeted you
personally.
>
> On Tue, Jul 22, 2014 at 12:10 AM, Ferenc Kovacs wrote
On Tue, Jul 22, 2014 at 11:32 AM, Pierre Joye wrote:
> On Tue, Jul 22, 2014 at 11:18 AM, Benjamin Eberlei
> wrote:
>
> > This is the opportunity to do the cleanup now, based on phpng branch.
> Since
> > the branch is pulic on Github, how is development secret?
>
> Benjamin, please check the back
On Tue, Jul 22, 2014 at 11:58 AM, Ferenc Kovacs wrote:
> On Tue, Jul 22, 2014 at 3:42 AM, Xinchen Hui wrote:
>
> > Hey:
> >
> > I really don't like arguing in english, so this will be my last
> > reply in this thread.
> >
>
> sorry to bother you, and my "backlash" wasn't really targeted you
On Tue, Jul 22, 2014 at 12:11 PM, Benjamin Eberlei wrote:
> On Tue, Jul 22, 2014 at 11:32 AM, Pierre Joye wrote:
>>
>> On Tue, Jul 22, 2014 at 11:18 AM, Benjamin Eberlei
>> wrote:
>>
>> > This is the opportunity to do the cleanup now, based on phpng branch.
>> > Since
>> > the branch is pulic on
On Mon, Jun 30, 2014 at 8:10 PM, Alexey Zakhlestin
wrote:
>
> On 30 Jun 2014, at 11:10, Stas Malyshev wrote:
>
> > I think we should move away from the practice of using serializer for
> > something it was never made for, namely a weird way of instantiating
> > classes. Serializer should be work
To unsubscribe from the lists you responded to (and appear to be
trying to unsubscribe from), please send a message to the following
addresses:
php-general-unsubscr...@lists.php.net
php-announce-unsubscr...@lists.php.net
internals-unsubscr...@lists.php.net
On 21 July 2014 07:18, Jon Arano wrote:
On Tue, Jul 22, 2014 at 12:15 PM, Nikita Popov wrote:
> On Tue, Jul 22, 2014 at 11:58 AM, Ferenc Kovacs wrote:
>
>> On Tue, Jul 22, 2014 at 3:42 AM, Xinchen Hui wrote:
>>
>> > Hey:
>> >
>> > I really don't like arguing in english, so this will be my last
>> > reply in this thread.
>> >
>>
On Tue, Jul 22, 2014 at 12:27 PM, Ferenc Kovacs wrote:
> sorry for the late reply.
> you are right and after looking into the implementation I think classes
> having custom object storage (eg. create_object) shouldn't assume that
> their __construct will be called, but either do the initializatio
On Tue, Jul 22, 2014 at 1:48 PM, Nikita Popov wrote:
> On Tue, Jul 22, 2014 at 12:27 PM, Ferenc Kovacs wrote:
>
>> sorry for the late reply.
>> you are right and after looking into the implementation I think classes
>> having custom object storage (eg. create_object) shouldn't assume that
>> the
On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski wrote:
>
>
> He just asks if we will have a 5.7 release while working on the next major
> in master.
>
> I don't think that we can release the php-next under a years, so I think
> that an 5.7 could be warranted (to keep up with our roadmap), but depe
On Mon, Jul 14, 2014 at 6:35 PM, Nikita Popov wrote:
> On Mon, Jul 7, 2014 at 4:18 PM, Nikita Popov wrote:
>
> > Hi internals!
> >
> > I've started the vote on the Uniform Variable Syntax RFC:
> >
> > https://wiki.php.net/rfc/uniform_variable_syntax#vote
> >
> > You can review the discussion
On 22/07/14 13:17, Ferenc Kovacs wrote:
> The discussion seems to be sidetracked by the topic on when should we
> release PHP-NEXT and what else should it contains.
> Could we agree to put that aside for now, and agree to discuss this later,
> after we managed to have a consensus on merging phpng t
On 22 Jul 2014, at 13:38, Ferenc Kovacs wrote:
> Derick mentioned in his blogpost(
> http://derickrethans.nl/uniform-variable-syntax.html) that "You can't
> really write a scanner for it, as the code could already have been
> converted.”.
Of course what he said was true, but I’m not sure it’s i
On Tue, Jul 22, 2014 at 2:17 PM, Ferenc Kovacs wrote:
> Hi Zeev,
>
> The discussion seems to be sidetracked by the topic on when should we
> release PHP-NEXT and what else should it contains.
> Could we agree to put that aside for now, and agree to discuss this later,
> after we managed to have a
On 22 ביול 2014, at 15:17, Ferenc Kovacs wrote:
> Hi Zeev,
>
> The discussion seems to be sidetracked by the topic on when should we release
> PHP-NEXT and what else should it contains.
> Could we agree to put that aside for now, and agree to discuss this later,
> after we managed to have a co
Hi Ferenc,
> On 22.07.2014, at 14:38, Ferenc Kovacs wrote:
>
> On Mon, Jul 14, 2014 at 6:35 PM, Nikita Popov wrote:
>
>> On Mon, Jul 7, 2014 at 4:18 PM, Nikita Popov wrote:
>>
>>> Hi internals!
>>>
>>> I've started the vote on the Uniform Variable Syntax RFC:
>>>
>>>https://wiki.php.n
On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski wrote:
> Once the RFC is approved (I hope)
>
Before the merge RFC can be considered for voting, I think it is critical
that you provide a comprehensive migration guide highlighting the changes
required from core developers.
This means https://wiki.ph
Andrea Faulds wrote (on 20/07/2014):
I’ve cancelled the vote because I don’t think the case for 6 is sufficiently
fleshed out. The RFC is now massively imbalanced in favour of 7, which isn’t
really fair to the 6 side, and I don’t think we can hold a vote while that’s
still the case.
I've onl
On Tue, 22 Jul 2014, Etienne Kneuss wrote:
> On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski wrote:
>
> > Once the RFC is approved (I hope)
>
> Before the merge RFC can be considered for voting, I think it is
> critical that you provide a comprehensive migration guide highlighting
> the changes
I'll try to do this.
It would be great, if someone may help.
Thanks. Dmitry.
On Tue, Jul 22, 2014 at 5:18 PM, Etienne Kneuss
wrote:
> On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski wrote:
>
> > Once the RFC is approved (I hope)
> >
>
> Before the merge RFC can be considered for voting, I think
On 22/07/14 14:37, Derick Rethans wrote:
>> Before the merge RFC can be considered for voting, I think it is
>> > critical that you provide a comprehensive migration guide highlighting
>> > the changes required from core developers. This means
>> > https://wiki.php.net/phpng-upgrading should be
Jannik Zschiesche wrote (on 22/07/2014):
the point Derick was trying to make is that you can’t build a scanner that
automatically checks whether you rewrote this particular piece of code already
or not.
You can find the code pieces which match the constructs affected by the BC, but
the scanner
On 22 Jul 2014, at 14:47, Rowan Collins wrote:
> I thought for each ambiguous case whose behaviour would change, there is a
> pair of unambiguous forms (one for each interpretation) which work the same
> under both parsers?
That’s correct. For projects you want to run on both PHP 5 and PHP 6,
On 22 Jul 2014, at 14:27, Rowan Collins wrote:
> the RFC would be much better with a different structure. Currently, it's laid
> out in what you might call an "adversarial" style - arguments for one side,
> then arguments for the other; this doesn't lend itself well to summarising
> all the p
On Tue, Jul 22, 2014 at 2:56 PM, Andrea Faulds wrote:
>
> On 22 Jul 2014, at 14:27, Rowan Collins wrote:
>
> Maybe if I have some time I’ll try to restructure the RFC.
> --
> Andrea Faulds
> http://ajf.me/
>
>
Or, (maybe this is controversial in itself), drop the entire thing.
Until there is in
On 22/07/2014 15:37, Derick Rethans wrote:
> On Tue, 22 Jul 2014, Etienne Kneuss wrote:
>
>> On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski wrote:
>>
>>> Once the RFC is approved (I hope)
>>
>> Before the merge RFC can be considered for voting, I think it is
>> critical that you provide a compreh
On 22 Jul 2014, at 15:12, Jonny Stirling wrote:
> Or, (maybe this is controversial in itself), drop the entire thing.
>
> Until there is in fact, a next major version, what its name will be is surely
> moot, and until there is a GA release (or at the earliest alphas / beta test
> releases), t
Yasuo,
> However, I don't mind at all to write RFC raising E_NOTICE for
> password_hash()
> with PASSWORD_BCRYPT.
Awesome, thanks!
> Although cryptgraphic hash functions are supposed work cryptgraphic way, but
> many of them are failing. This was in real world and I aware of the risk.
It's le
On Tue, Jul 22, 2014 at 4:10 PM, Matteo Beccati wrote:
> On 22/07/2014 15:37, Derick Rethans wrote:
> > On Tue, 22 Jul 2014, Etienne Kneuss wrote:
> >
> >> On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski wrote:
> >>
> >>> Once the RFC is approved (I hope)
> >>
> >> Before the merge RFC can be cons
On Tue, Jul 22, 2014 at 3:22 PM, Andrea Faulds wrote:
>
> On 22 Jul 2014, at 15:12, Jonny Stirling
> wrote:
>
> > Or, (maybe this is controversial in itself), drop the entire thing.
> >
> > Until there is in fact, a next major version, what its name will be is
> surely moot, and until there is a
Hi,
On Tue, Jul 22, 2014 at 3:18 PM, Etienne Kneuss wrote:
> This means https://wiki.php.net/phpng-upgrading should be completed to
> reflect all changes.
as a pure consumer maintaining some internal extensions, I would very
much like to see this too, at least when you decide to go ahead with
t
Or, (maybe this is controversial in itself), drop the entire thing.
Until there is in fact, a next major version, what its name will be is
surely moot, and until there is a GA release (or at the earliest alphas /
beta test releases), there should be no such thing as a versioned /
numbered release
> -Original Message-
> From: Kris Craig [mailto:kris.cr...@gmail.com]
> Sent: Tuesday, July 22, 2014 8:59 AM
> To: Michael Wallner
> Cc: Andrea Faulds; PHP Internals; Derick Rethans; Nikita Popov
> Subject: Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP
>
>
> Andrea and Zeev,
>
> If
On Tue, Jul 22, 2014 at 4:35 PM, Brian Moon wrote:
> Or, (maybe this is controversial in itself), drop the entire thing.
>>
>> Until there is in fact, a next major version, what its name will be is
>> surely moot, and until there is a GA release (or at the earliest alphas /
>> beta test releases)
On 22 Jul 2014, at 15:38, Zeev Suraski wrote:
> I made some more edits and I think the Case for 7 is ready.
>
> We're ready to go to a vote as early as tomorrow as far as I'm concerned…
I quite like what you’ve done to the PHP 6 section, it’s much nicer than it was
before, thanks!
With the R
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Tuesday, July 22, 2014 4:56 PM
> To: Rowan Collins
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP
>
> Maybe if I have some time I'll try to restructure the RFC.
Please don't.
I think the way it's la
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Tuesday, July 22, 2014 5:42 PM
> To: Zeev Suraski
> Cc: Kris Craig; PHP Internals
> Subject: Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP
>
>
> On 22 Jul 2014, at 15:38, Zeev Suraski wrote:
>
> > I made some m
On 22 Jul 2014, at 15:48, Zeev Suraski wrote:
>> Maybe if I have some time I'll try to restructure the RFC.
>
> Please don’t.
I was going to, but I’m actually happy with it now, so I won’t bother.
> To those who are saying 'let's bury it for now', I absolutely think we
> should go all the way
On 22 Jul 2014, at 15:51, Zeev Suraski wrote:
> You're welcome! But really, the glory belongs to Nikita - he rewrote this
> section (and moved it below the Case for 7, for whatever reasons :)
Actually, I moved it below the Case for 7, because I realised that most of the
case for PHP 6 is just
On 22/07/14 15:30, Jonny Stirling wrote:
> PHP6 / 7 / whatever, does not exist, and will not exist (like I said) until
> official releases as the next major version are put out. Tis a pretty
> simple solution for a problem that does not actually exist in the present.
PHP6 existed - it was simply n
Maybe then an option should be added to vote "not now" or similar. You're
forcing people into a decision for this or that when some may not wish for
the decision to be made right now, and without the ability to abstain from
either option.
Neither of you are going to change your minds anyway, and s
On Tue, Jul 22, 2014 at 2:04 PM, Ferenc Kovacs wrote:
>
>
>
> On Tue, Jul 22, 2014 at 1:48 PM, Nikita Popov wrote:
>>
>> On Tue, Jul 22, 2014 at 12:27 PM, Ferenc Kovacs wrote:
>>>
>>> sorry for the late reply.
>>> you are right and after looking into the implementation I think classes
>>> having
Zeev Suraski wrote (on 22/07/2014):
I think the way it's laid out right now makes sense. Let's not try to
sweep this under the carpet - we two mutually exclusive options and we
need to decide between them.
How is laying out the arguments more clearly "sweeping it under the
carpet"? The *outco
> On 22 ביול 2014, at 19:25, Rowan Collins wrote:
>
> Zeev Suraski wrote (on 22/07/2014):
>> I think the way it's laid out right now makes sense. Let's not try to
>> sweep this under the carpet - we two mutually exclusive options and we
>> need to decide between them.
>
> How is laying out the ar
Zeev Suraski wrote (on 22/07/2014):
If I understood you correctly you seem to believe that we should aim
for consensus when it's pretty clear there isn't going to be one. I
can't see how shuffling the points around under topics will somehow
help us create such consensus. Knowing many of the pe
I got the vibe that people weren't happy with the RFC, and that's why
the vote was cancelled, so I was suggesting a way forward, but maybe I
misread the situation.
I think that was 2 days and many, many emails ago. The parties that
expressed an opinion on the RFC which led to the vote being can
On 22 Jul 2014, at 18:21, Rowan Collins wrote:
> I got the vibe that people weren't happy with the RFC, and that's why the
> vote was cancelled, so I was suggesting a way forward, but maybe I misread
> the situation.
I cancelled it because Zeev’s edits took me by surprise. It was rather
hypo
Brian Moon wrote (on 22/07/2014):
I got the vibe that people weren't happy with the RFC, and that's why
the vote was cancelled, so I was suggesting a way forward, but maybe I
misread the situation.
I think that was 2 days and many, many emails ago. The parties that
expressed an opinion on the
On Tue, Jul 22, 2014 at 7:47 PM, Rowan Collins wrote:
> Brian Moon wrote (on 22/07/2014):
>
>>> I got the vibe that people weren't happy with the RFC, and that's why
>>> the vote was cancelled, so I was suggesting a way forward, but maybe I
>>> misread the situation.
>>
>>
>> I think that was 2 da
Hi!
> According to PHP 5.3 EOL RFC, we've now a month past official EOL date,
> but we've planned to make one final release incorporating most important
> fixes from upper branches since the last 5.3 release. To help with that,
> I've created a pull here:
>
> https://github.com/php/php-src/pull/7
Hi,
On Tue, 2014-07-22 at 11:53 -0700, Stas Malyshev wrote:
> Hi!
>
> > According to PHP 5.3 EOL RFC, we've now a month past official EOL date,
> > but we've planned to make one final release incorporating most important
> > fixes from upper branches since the last 5.3 release. To help with that,
Morning,
I propose deprecating two GD functions: imagettftext and imagettfbbox.
The reasons I would like to deprecate them are:
1. Their functionality is a subset of imagefttext and imageftbbox
2. The imagettf* functions have the same requirements as the imageft* functions
3. The imagettf* functi
On Tue, Jul 22, 2014 at 8:59 PM, Johannes Schlüter wrote:
> Hi,
>
> On Tue, 2014-07-22 at 11:53 -0700, Stas Malyshev wrote:
> > Hi!
> >
> > > According to PHP 5.3 EOL RFC, we've now a month past official EOL date,
> > > but we've planned to make one final release incorporating most
> important
>
Hi!
> Thanks for the work! The list looks good. Any opinions on #67541? WHich
> was requested there? going strict by the rules it won't qualify.
In principle, I don't have anything against it but I'm not familiar with
the code there enough to understand the full set of consequences. I'd
like to h
Hi!
> not sure, have you seen https://bugs.php.net/bug.php?id=67606 ?
This is worrying. Looks like the patch is not as safe as we've hoped,
and causes BC issues for mod_fastcgi, so maybe we should not get it into
5.3. Once it stabilizes, we can backport it into 5.4, but for 5.3 better
safe than s
On Tue, 2014-07-22 at 21:05 +0200, Ferenc Kovacs wrote:
>
> Thanks for the work! The list looks good. Any opinions on
> #67541? WHich
> was requested there? going strict by the rules it won't
> qualify.
>
> johannes
>
>
>
> not s
On 22 Jul 2014, at 21:10, Stas Malyshev wrote:
> Hi!
>
>> not sure, have you seen https://bugs.php.net/bug.php?id=67606 ?
>
> This is worrying. Looks like the patch is not as safe as we've hoped,
> and causes BC issues for mod_fastcgi, so maybe we should not get it into
> 5.3. Once it stabilize
Just announced something at OSCON that's probably going to get a lot
of folks talking and making assumptions, so before things get out of
hand, I want to provide some context.
We (As in PHP) have been talking about making a spec for the PHP
language for a LONG time. With PHPNG around the corner,
On Tue, 2014-07-22 at 21:41 +0200, David Zuelke wrote:
> On 22 Jul 2014, at 21:10, Stas Malyshev wrote:
>
> > Hi!
> >
> >> not sure, have you seen https://bugs.php.net/bug.php?id=67606 ?
> >
> > This is worrying. Looks like the patch is not as safe as we've hoped,
> > and causes BC issues for m
Hi all,
I like to create an RFC to add an unsinged integer type for the
following purposes:
- higher max value
- DBs already allow UNSIGNED INT/BIGINT which is a farce to work with
in PHP
- better support pack/unpack unsigned integers from/to PHP using the
un/pack functions
- simplified right s
Hi all,
I have a new email address ending "@mabe.berlin" but I can't confirm
this in the ML :(
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi all,
I like to create an RFC to add an unsinged integer type for the
following purposes:
- higher max value
- DBs already allow UNSIGNED INT/BIGINT which is a farce to work with
in PHP
- better support pack/unpack unsigned integers from/to PHP using the
un/pack functions
- simplified right s
Hi all,
I like to create an RFC to add an unsinged integer type for the
following purposes:
- higher max value
- DBs already allow UNSIGNED INT/BIGINT which is a farce to work with
in PHP
- better support pack/unpack unsigned integers from/to PHP using the
un/pack functions
- simplified right s
On 22/07/2014 20:55, Marc Bennewitz wrote:
I like to create an RFC to add an unsinged integer type
+1 for not turning the iron up too high when doing your maths!
[https://en.wiktionary.org/wiki/singe]
Sorry, it's a common typo, but it made me chuckle that you used it in
both the subject and
Sara, I can't even begin to thank you and your team enough for this. This
is incredibly huge.
You're right, a spec has become even more important with new engines and
implementations like PHPNG and HHVM in the works. I wondered if this were
to ever happen. It never seemed like anyone in the PHP co
On Tue, Jul 22, 2014 at 9:55 PM, Marc Bennewitz
wrote:
> Hi all,
>
> I like to create an RFC to add an unsinged integer type for the
> following purposes:
>
> - higher max value
> - DBs already allow UNSIGNED INT/BIGINT which is a farce to work with
> in PHP
> - better support pack/unpack unsig
ups (typo + copy past error)
It's not my day today!
On 22.07.2014 22:21, Rowan Collins wrote:
> On 22/07/2014 20:55, Marc Bennewitz wrote:
>> I like to create an RFC to add an unsinged integer type
>
> +1 for not turning the iron up too high when doing your maths!
>
> [https://en.wiktionary.org
I mean a new scalar type here
On 22.07.2014 22:33, Nikita Popov wrote:
> On Tue, Jul 22, 2014 at 9:55 PM, Marc Bennewitz
> wrote:
>
>> Hi all,
>>
>> I like to create an RFC to add an unsigned integer type for the
>> following purposes:
>>
>> - higher max value
>> - DBs already allow UNSIGNED I
On 22 Jul 2014, at 18:50, Marc Bennewitz wrote:
> I like to create an RFC to add an unsinged integer type for the
> following purposes:
>
> - higher max value
> - DBs already allow UNSIGNED INT/BIGINT which is a farce to work with
> in PHP
> - better support pack/unpack unsigned integers from/
On 22 Jul 2014, at 20:50, Sara Golemon wrote:
> To that end, we (as in Facebook), have been putting together a formal
> language spec for PHP (using PHP 5.6 as the source of truth) along
> with an additional conformance test suite (which compliments
> Zend/tests). We've talked to some engine fo
On 22 Jul 2014, at 21:21, Rowan Collins wrote:
> More seriously, UnsignedInt might go nicely alongside Andrea's BigInts…
Bigints kinda remove the need for unsigned ints as you’d be able to use big
signed integers of any size. I also really don’t want unsigned int because it
makes integer sema
On Tue, Jul 22, 2014 at 12:50 PM, Sara Golemon wrote:
> This document is meant for PHP, and PHP should be the steward of it
> going forward, so we (as in PHP) should start looking at good ways to
> keep it up to date and revise it over time.
>
Some folks in IRC asked for clarification of this poin
hi Bob,
I still think that current array usage in constant expressions is not
consistent and dangerous. It "smells" to me, and I think it may bring
troubles in the future even if the existing known bugs are fixed.
I see few issues:
1) It is possible to declare array class constants however they
On 22 Jul 2014, at 23:22, Sara Golemon wrote:
> We're happy to setup the framework for curating that document
> (probably as a github project), but don't want to be all controlling
> with it, so if the PHP Group as an organization wants to own it and
> manage updates to it over time, all the bet
On Tue, Jul 22, 2014 at 3:09 PM, Andrea Faulds wrote:
> Good luck documenting PHP’s inconsistent semantics, though.
> It’ll either be endlessly detailed, or not matching PHP 5.6.
> To be honest, I think we should probably clean up PHP’s
> semantics so they can be more clearly specified.
>
200 page
On 22 Jul 2014, at 23:32, Sara Golemon wrote:
> As you suppose, some of that bulk is down to the kinds of things that
> the Unified Variable Syntax RFC is trying to resolve. On the plus
> side, the guy who's been writing the spec is insanely detail oriented
> (and has experience writing languag
Hi!
> To that end, we (as in Facebook), have been putting together a formal
> language spec for PHP (using PHP 5.6 as the source of truth) along
> with an additional conformance test suite (which compliments
> Zend/tests). We've talked to some engine folks along the way to get
> feedback and make
On Tue, Jul 22, 2014 at 3:34 PM, Andrea Faulds wrote:
> On 22 Jul 2014, at 23:32, Sara Golemon wrote:
>> As you suppose, some of that bulk is down to the kinds of things that
>> the Unified Variable Syntax RFC is trying to resolve. On the plus
>> side, the guy who's been writing the spec is insa
On 7/22/14, 5:32 PM, Sara Golemon wrote:
On Tue, Jul 22, 2014 at 3:09 PM, Andrea Faulds wrote:
Good luck documenting PHP’s inconsistent semantics, though.
It’ll either be endlessly detailed, or not matching PHP 5.6.
To be honest, I think we should probably clean up PHP’s
semantics so they can b
On 22 Jul 2014, at 23:37, Larry Garfield wrote:
> The big question here, though, is whether, going forward, we'll be able to
> mentally switch to a "spec first" mentality. If not, the spec will get out
> of date and become less than useful. I hope we're able to make that
> transition.
I th
Hi Andrea,
very nice RFC!
You have added the new type internally only. Does it make sense or would
it be possible to use one more internal type like "ULONG" to safe
mem/cpu in such cases because bigint/GMP objects are used only on much
higher numbers?
Marc
On 23.07.2014 00:12, Andrea Faulds wro
On Jul 22, 2014, at 5:41 PM, Andrea Faulds wrote:
> On 22 Jul 2014, at 23:37, Larry Garfield wrote:
>
>> The big question here, though, is whether, going forward, we'll be able to
>> mentally switch to a "spec first" mentality. If not, the spec will get out
>> of date and become less than us
On 22 Jul 2014, at 23:43, Marc Bennewitz wrote:
> You have added the new type internally only. Does it make sense or would
> it be possible to use one more internal type like "ULONG" to safe
> mem/cpu in such cases because bigint/GMP objects are used only on much
> higher numbers?
You *could* d
On Tue, Jul 22, 2014 at 3:41 PM, Andrea Faulds wrote:
> On 22 Jul 2014, at 23:37, Larry Garfield wrote:
>> The big question here, though, is whether, going forward, we'll be
>> able to mentally switch to a "spec first" mentality. If not, the spec will
>> get out of date and become less than usef
On 22 Jul 2014, at 23:48, Sara Golemon wrote:
> On Tue, Jul 22, 2014 at 3:41 PM, Andrea Faulds wrote:
>> On 22 Jul 2014, at 23:37, Larry Garfield wrote:
>>> The big question here, though, is whether, going forward, we'll be
>>> able to mentally switch to a "spec first" mentality. If not, the
On Tue, Jul 22, 2014 at 3:56 PM, Andrea Faulds wrote:
> Ah, I think you misunderstand. What I mean is that we
> should only propose RFCs which change the spec
> when there is already a working implementation first.
> Otherwise, we might add things to the spec which won’t
> or can’t get implemented
On 23 Jul 2014, at 00:01, Sara Golemon wrote:
> Our RFCs tend to have implementations attached to them (in someone's
> personal fork). IMO we should make creating the spec PR part of the
> RFC acceptance process, and that they should be landed together. I
> agree it doesn't make much sense to d
Hi Anthony,
On Tue, Jul 22, 2014 at 11:27 PM, Anthony Ferrara
wrote:
> > However, I don't mind at all to write RFC raising E_NOTICE for
> > password_hash()
> > with PASSWORD_BCRYPT.
>
> Awesome, thanks!
>
I'll write it later.
> Although cryptgraphic hash functions are supposed work cryptgraph
On Tue, Jul 22, 2014 at 3:28 PM, Stas Malyshev
wrote:
> Hi!
>
> > To that end, we (as in Facebook), have been putting together a formal
> > language spec for PHP (using PHP 5.6 as the source of truth) along
> > with an additional conformance test suite (which compliments
> > Zend/tests). We've t
Hi,
How can I know the line no in eval()'d code?
e.g eval()'d code on line 1 (I couldn't find the definition of that
output, so I had to ask it here)
zend_get_executed_lineno(TSRMLS_C) doesn't seem to be the right value
Also, I'm not sure how to tell if the code is in eval() either
--
Best Re
1 - 100 of 103 matches
Mail list logo
