Hi Kalle,
Thank you for the list. It's very helpful!
On Fri, Dec 5, 2014 at 4:58 AM, Kalle Sommer Nielsen ka...@php.net wrote:
2014-12-04 9:28 GMT+01:00 Yasuo Ohgaki yohg...@ohgaki.net:
Any comments?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
I think we should solve these on a
On 08/02/15 06:37, Yasuo Ohgaki wrote:
Hi Lester,
PHP7 is proposing a LOT of shiny new features which will break much
legacy code. So the question has to be just what is the plan regarding
cross version support. I see that the general consensus is PHP5 should
just run?
Do
Am 08.02.2015 03:39 schrieb Rasmus Lerdorf ras...@lerdorf.com:
Basically declare() does not respect function scope, but it doesn't let
you know that. There is a reason we haven't used declare() for anything
real.
That is absolutely awful. But it's a fault with declare. Can't that be
fixed
Hi Matthew,
On Sat, Feb 7, 2015 at 5:29 AM, Matthew Leverton lever...@gmail.com wrote:
On Fri, Feb 6, 2015 at 1:02 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Basically, it's administrative solution. Application should set these
setting
or administrator should.
Library shouldn't
On Sat, Feb 7, 2015 at 11:11 PM, Andrea Faulds a...@ajf.me wrote:
Hi,
On 7 Feb 2015, at 22:03, Pavel Kouřil pajou...@gmail.com wrote:
Yeah, but you say in the RFC that With this approach, an argument is
only accepted if its type is exactly the same as the parameter. when
speaking about C#
On Sun, Feb 8, 2015 at 3:38 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 02/07/2015 05:03 PM, Pavel Kouřil wrote:
I'm wishing more and more that the RFC doesn't pass (even though I'd
LOVE to have typehints in PHP as a userland developer) and someone
else will make a better version of
Lester Caine wrote in message news:54d73248.9030...@lsces.co.uk...
On 08/02/15 06:37, Yasuo Ohgaki wrote:
Hi Lester,
PHP7 is proposing a LOT of shiny new features which will break much
legacy code. So the question has to be just what is the plan
regarding
cross version support.
Hi!
I'd like to announce a vote on parameter skipping RFC:
https://wiki.php.net/rfc/skipparams
TLDR: it allows using default to specify that parameter has the
default value when calling function with optional parameter, like this:
create_query(deleted=0, name, default, /*report_errors*/ true)
Hi Guilherme and Francois,
Could you give your ideas for these?
Thank you.
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Sun, Feb 8, 2015 at 5:16 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Dimitry, Francois and Guilherme,
On Thu, Feb 5, 2015 at 8:14 PM, Dmitry Stogov dmi...@zend.com wrote:
Hi
Hi Dimitry, Francois and Guilherme,
On Thu, Feb 5, 2015 at 8:14 PM, Dmitry Stogov dmi...@zend.com wrote:
Hi Yasuo,
Following our conversation, I tried to imagine how DbC should look like in
PHP from user perspective. Finally, I was influenced by the semantic
proposed in D, and syntax
Hello everyone,
I've been following the Static type hints discussion for a while now. Aside
from its content, which there are some strong sentiments about, there's also
another recurring pattern - the wish for voting options instead of just
yes/no.
Along these lines I've created an RFC on one
Hi Timm,
On 8 Feb 2015, at 12:04, Timm Friebe p...@thekid.de wrote:
Hello everyone,
I've been following the Static type hints discussion for a while now.
Presumably you mean scalar not static.
Aside
from its content, which there are some strong sentiments about, there's also
another
Hi Lester,
On 07.02.2015 13:36, Lester Caine wrote:
My personal experience of PHP4 is simply one of having been developing
all my code in PHP5.0 to 5.2 but ensuring that the code also still run
clean on the PHP4 host.
Actually, PHP 4 changed a lot of things from PHP3. PHP 5.0.0 on the
other
Hi,
I personally see the benefits this could have but also the BC break this
would
introduce.
[...]
I don't see the point of this: the Scalar Type Hints RFC already has a voting
option on reserving the type names, and it is set to pass, so by the time your
RFC could go to a vote, it
-Ursprüngliche Nachricht-
Von: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Gesendet: Sonntag, 8. Februar 2015 04:53
An: Andrea Faulds
Cc: Pavel Kouřil; PHP Internals
Betreff: Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 02/07/2015 09:51 PM, Andrea Faulds wrote:
tan(1);
echo
On 08/02/2015 11:24, Tony Marston wrote:
Well said. If it is not possible to have a single codebase that runs in
both PHP 5 *AND* PHP 7 then that will be a total disaster.
Of course you can have a single codebase running both on PHP5 and PHP7,
unless you want to use PHP7-only features.
But
On 08/02/15 11:43, Ralf Lang wrote:
A lot of sites sticked with PHP5.3 because they were driven by
enterprise platforms which by definition won't upgrade during the life
cycle. That had its own costs and aches which are entirely not PHP's fault.
PHP7 is proposing a LOT of shiny new features
Hi Leigh,
On 2/8/15, 12:33 PM, Leigh lei...@gmail.com wrote:
Are we happy to accept that we'll lose access to some of mcrypts
ciphers if we do this? I'd suspect most real world usage of php-mcrypt
is to implement AES anyway, so most users would be covered.
I hope your suspicion is right.
I'd
On 07/02/2015 01:08, Sebastian Bergmann wrote:
On 02/06/2015 10:22 PM, Nikita Popov wrote:
After much initial reluctance, I've voted in favor of this RFC.
After reading your email, Nikita, I deleted my vote (it was no before).
I will review the RFC again, with your arguments (and others)
On 08/02/2015 11:45, Matteo Beccati wrote:
On 08/02/2015 11:24, Tony Marston wrote:
Well said. If it is not possible to have a single codebase that runs in
both PHP 5 *AND* PHP 7 then that will be a total disaster.
Of course you can have a single codebase running both on PHP5 and
PHP7,
On 8 February 2015 at 17:03, Pierre Joye pierre@gmail.com wrote:
I agree with Derick about wrapping ext/mcrypt around OpenSSL or other to
keep it around for BC. I simply do not have the resources to make that
happen so someone has to jump on it (Derick?)
Are we happy to accept that we'll
On Sun, Feb 8, 2015 at 12:11 PM, Tom Worster f...@thefsb.org wrote:
Thanks Damien and Daniel for the info.
I am not concerned about running out of entropy. I am concerned about
userspace RNGs such as OpenSSL
http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
Just to be
On Thu, Feb 5, 2015 at 10:41 PM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
My biggest concern about all this breakage done for NG could somehow be
minimized by providing possible alternate implementations that could work
both backwards compatible and forwards compatible?
I
On 08/02/2015 12:30, Lester Caine wrote:
Currently it is impossible to run the PHP5.2 code base on PHP5.4. That
is a simple fact. So I can't do between 5.2 and 5.4 what I am currently
doing between 5.4 and 7. The code has to be reworked ... so what ever
anybody says PHP5 .4*IS* PHP6 in terms of
On Sun, Feb 8, 2015 at 4:24 AM, Tom Worster f...@thefsb.org wrote:
3. Will the OpenSSL ext remain as it currently stands?
There has been talk of replacing it with a more generic implementation that
can swap out the underlying components so we aren't dependent upon a single
library. The crypto
Tom Worster f...@thefsb.org schreef op 8 februari 2015 15:38:15 GMT+00:00:
mycrypt was abandoned by its developers in 2007. The package in Debian
is
from 2009. It has been removed from RHEL.
This is already unacceptable. But it would be an insult to the idea of
security to include mcrypt in PHP
On Sun, Feb 8, 2015 at 5:15 PM, Daniel Lowrey rdlow...@php.net wrote:
Currently PHP's openssl_random_pseudo_bytes() uses the latter function and
allows users to pass a by-reference $crypto_strong out parameter to
determine if the result is cryptographically strong. This is fine if you
know
On Feb 8, 2015 10:44 PM, Tom Worster f...@thefsb.org wrote:
Hi Yasuo, Pierre,
Thank you both for the updates.
I expect the vote to remove mcrypt can be shifted towards yes if some
campaigning effort is made. I made a start in another thread.
Assuming that mcrypt goes, as it should, we are
Hi Derick,
On 2/8/15, 11:38 AM, Derick Rethans der...@php.net wrote:
Btw, I only voted no because I don't think we should just remove it. A
reimplementation of its APIs on top of eg. Open SSL makes sense. And that
I'd vote yes for.
This idea makes me nervous. It doesn't sound at all easy and
Thanks Damien and Daniel for the info.
I am not concerned about running out of entropy. I am concerned about
userspace RNGs such as OpenSSL
http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
On 2/8/15, 12:04 PM, Damien Tournoud d...@damz.org wrote:
On Sun, Feb 8, 2015 at
Hi Yasuo, Pierre,
Thank you both for the updates.
I expect the vote to remove mcrypt can be shifted towards yes if some
campaigning effort is made. I made a start in another thread.
Assuming that mcrypt goes, as it should, we are left with a problem. The
PHP user doesn't have a
mycrypt was abandoned by its developers in 2007. The package in Debian is
from 2009. It has been removed from RHEL.
This is already unacceptable. But it would be an insult to the idea of
security to include mcrypt in PHP 7.
The vote to remove mcrypt is at present tied roughly 13:13. If you have
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
Since people's preferences are diverse. It might be a good idea having
pre-vote
for designs, then we may have final vote with single design.
We need some consensuses even for pre-vote.
What do you think?
What I
Hi Timm
2015-02-08 13:04 GMT+01:00 Timm Friebe p...@thekid.de:
Hello everyone,
I've been following the Static type hints discussion for a while now. Aside
from its content, which there are some strong sentiments about, there's also
another recurring pattern - the wish for voting options
Hi,
On 8 Feb 2015, at 13:32, Timm Friebe p...@thekid.de wrote:
I personally see the benefits this could have but also the BC break this
would
introduce.
[...]
I don't see the point of this: the Scalar Type Hints RFC already has a voting
option on reserving the type names, and it is set
On 8 Feb 2015, at 15:48, Andrea Faulds a...@ajf.me wrote:
If this RFC would somehow pass, yes. However, you’re introducing a competing
proposal at the “eleventh hour”, so to speak, which is terribly nice. Unless
there’s a radical shift in how people vote on the Scalar Type Hints RFC, it
De : Jordi Boggiano [mailto:j.boggi...@seld.be]
Envoyé : dimanche 8 février 2015 19:12
À : internals@lists.php.net
Objet : Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 07/02/2015 01:08, Sebastian Bergmann wrote:
On 02/06/2015 10:22 PM, Nikita Popov wrote:
After much initial reluctance,
On Sun, Feb 8, 2015 at 1:48 PM, Zeev Suraski z...@zend.com wrote:
proposal everyone can rally behind, it very clearly failed. We didn't have
to wait for a vote by the way, it was clear from the discussion on
internals@.
Controversial RFCs are precisely the ones that SHOULD be voted on.
-Original Message-
From: Matthew Leverton [mailto:lever...@gmail.com]
Sent: Sunday, February 08, 2015 11:17 PM
To: Zeev Suraski
Cc: Jordi Boggiano; PHP internals
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Sun, Feb 8, 2015 at 1:48 PM, Zeev Suraski z...@zend.com wrote:
Hello,
First of all, thank you for php. Secondly, I hope this doesn't come
across as impertinent.
I'm an average user of php. I don't know enough about programming
languages to contribute
here; but I do try and keep up with what's going on in the php core.
I was curious what the userland view
Hi,
On 8 Feb 2015, at 21:48, Marc Bennewitz dev@mabe.berlin wrote:
Wrapping all in objects isn't an option. This would only add unnecessary
overhead and only move the issue to a different place.
I don’t see why not. Objects are generally exempt from type juggling, except
for conversion to
On 08/02/2015 09:20, Patrick Schaaf wrote:
Am 08.02.2015 03:39 schrieb Rasmus Lerdorf ras...@lerdorf.com:
Basically declare() does not respect function scope, but it doesn't let
you know that. There is a reason we haven't used declare() for anything
real.
That is absolutely awful. But it's a
On 08/02/2015 09:03, Yasuo Ohgaki wrote:
If this was a PHP_INI_PERDIR setting, then I wouldn't really mind as much.
But as PHP_INI_USER, I don't like it at all.
How about allow to set the ini only once during execution?
Like open_baedir [1], it should probably be possible to *tighten* the
Hi all,
Since PHP-5.2.1 we have an artifact of PHP-6 in the engine means we can
define binary strings but such definitions haven't any effect.
So what we can define is the following:
$str = str;
$bin = bb\0i\0n;
$str2bin = (binary)$str;
One of the biggest issue is that currently ALL strings
FWIW, while I think strict types - stricter than even strict languages -
don't belong in PHP, this syntax is clearly a step up from declare(), which
was definitely not intended for this purpose.
Zeev
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Sunday, February
On Sun, Feb 8, 2015 at 2:18 PM, Tom Worster f...@thefsb.org wrote:
On 2/8/15, 12:52 PM, Daniel Lowrey rdlow...@php.net wrote:
On Sun, Feb 8, 2015 at 12:11 PM, Tom Worster f...@thefsb.org wrote:
Thanks Damien and Daniel for the info.
I am not concerned about running out of entropy. I am
On 08/02/15 19:00, Rowan Collins wrote:
We have a single code base happily running on 5.2, 5.3, 5.4, and I think
even 5.5, so it is definitely possible with some code bases. There were
a few pieces that had to be changed to work right under 5.3 and 5.4, but
none for which the new solution
Hi François,
On 8 Feb 2015, at 20:43, François Laupretre franc...@tekwire.net wrote:
De : Andrea Faulds [mailto:a...@ajf.me]
Instead, I’m wondering if the following might be better:
?php strict
Which would be used like so:
?php strict
function foobar(): int {
On 2/8/15, 12:52 PM, Daniel Lowrey rdlow...@php.net wrote:
On Sun, Feb 8, 2015 at 12:11 PM, Tom Worster f...@thefsb.org wrote:
Thanks Damien and Daniel for the info.
I am not concerned about running out of entropy. I am concerned about
userspace RNGs such as OpenSSL
Hi,
I’m posting this in a new thread since people might (reasonably) be ignoring
further responses to the [VOTE] thread.
I’m considering a small change to the Scalar Type Hints RFC, specifically about
syntax. Quite a few people have said they don’t like the declare() syntax, and
it’s easy to
Zeev,
On 8 Feb 2015, at 19:48, Zeev Suraski z...@zend.com wrote:
Last, voters should take into account that this isn't an 'either this RFC or
nothing' situation. I think it's very unfortunate that the original RFC -
that had zero controversy surrounding it - was never put to a vote.
-Original Message-
From: Jordi Boggiano [mailto:j.boggi...@seld.be]
Sent: Sunday, February 08, 2015 8:12 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 07/02/2015 01:08, Sebastian Bergmann wrote:
On 02/06/2015 10:22 PM, Nikita Popov wrote:
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Sunday, February 08, 2015 9:50 PM
To: Zeev Suraski
Cc: Jordi Boggiano; internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
Zeev,
On 8 Feb 2015, at 19:48, Zeev Suraski z...@zend.com wrote:
De : Andrea Faulds [mailto:a...@ajf.me]
Instead, I’m wondering if the following might be better:
?php strict
Which would be used like so:
?php strict
function foobar(): int {
return 1.0; // error!
}
It’d be a per-file directive, so there’d be zero mixing
Rasmus Lerdorf in php.internals (Thu, 05 Feb 2015 17:28:37 -0500):
We have had quite a number of changes to the extension API and it
worries me a little bit how long it will take everyone to get their
extensions ported. We have UPGRADING.INTERNALS which still needs some
love, but even if that
Hi,
On 8 Feb 2015, at 20:10, Marc Bennewitz dev@mabe.berlin wrote:
Since PHP-5.2.1 we have an artifact of PHP-6 in the engine means we can
define binary strings but such definitions haven't any effect.
Yes. That’s because PHP 6 was going to have Unicode strings by default,
alongside
On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds a...@ajf.me wrote:
Good evening,
At long last, I’m going to put the RFC to a vote. It’s been long enough -
I don’t think there needs to be, or will be, much further discussion.
I’d like to make sure that everyone voting understands the RFC
Does anybody have a working Eclipse setup for building php-src and
extensions? I keep hitting 'phpsrc' when I try using google which just
about sums up how bad google is these days :(
As soon as one tries to drill down all one gets is pages with php in the
url ...
--
Lester Caine - G8HFL
Hi!
Are you saying performance is not the reason we use persistent handles?
It is, for databases where connection setup is expensive. Even then
persistent handles are not always the best solution. But with DB, you
routinely connect to one service, with one set of credentials, and need
this
Hi Ferenc,
On 8 Feb 2015, at 22:18, Ferenc Kovacs tyr...@gmail.com wrote:
I've voted no for two reasons:
1, I don't really like the the proposed declare solution, I know that you put
much thought and effort with finding a way to make the strict hints opt-in
for the caller, but I think it
Hi internals.
I really hope that in the future PHP 7, there will be new server API.
May be you interested to know about them, here is the link, I am not
the author of development:
https://github.com/unbit/uwsgi-phpsgi/
But the problem is that in PHP there are no standards for such interfaces.
Hi Francois,
On Mon, Feb 9, 2015 at 12:43 AM, François Laupretre franc...@tekwire.net
wrote:
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
Ohgaki
Since people's preferences are diverse. It might be a good idea having
pre-vote
for designs, then we may have final
Hi!
Last, voters should take into account that this isn't an 'either this RFC or
nothing' situation. I think it's very unfortunate that the original RFC -
that had zero controversy surrounding it - was never put to a vote.
Please stop repeating this, it is blatantly false and I’ve pointed
Hi,
On 8 Feb 2015, at 23:03, Stanislav Malyshev smalys...@gmail.com wrote:
Last, voters should take into account that this isn't an 'either this RFC or
nothing' situation. I think it's very unfortunate that the original RFC -
that had zero controversy surrounding it - was never put to a
Hi!
Following our conversation, I tried to imagine how DbC should look like in
PHP from user perspective. Finally, I was influenced by the semantic
proposed in D, and syntax proposed for Java. So, these are my initial
thoughts:
For php it may look like the following:
function foo()
On 08/02/2015 22:48, S.A.N wrote:
Hi internals.
I really hope that in the future PHP 7, there will be new server API.
May be you interested to know about them, here is the link, I am not
the author of development:
https://github.com/unbit/uwsgi-phpsgi/
But the problem is that in PHP there are
On 08/02/2015 20:53, Lester Caine wrote:
On 08/02/15 19:00, Rowan Collins wrote:
We have a single code base happily running on 5.2, 5.3, 5.4, and I think
even 5.5, so it is definitely possible with some code bases. There were
a few pieces that had to be changed to work right under 5.3 and 5.4,
On Mon, Feb 9, 2015 at 6:30 AM, Rowan Collins rowan.coll...@gmail.com wrote:
On 08/02/2015 20:33, Zeev Suraski wrote:
FWIW, while I think strict types - stricter than even strict languages -
don't belong in PHP, this syntax is clearly a step up from declare(),
which
was definitely not
Hi Stas,
On Mon, Feb 9, 2015 at 8:11 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Following our conversation, I tried to imagine how DbC should look like
in
PHP from user perspective. Finally, I was influenced by the semantic
proposed in D, and syntax proposed for Java. So, these are
2015-02-09 2:26 GMT+02:00 Rowan Collins rowan.coll...@gmail.com:
On 09/02/2015 00:02, S.A.N wrote:
You're right, but there is no threading issues.
One worker synchronously execute requests, but may run parallel many
workers.
I'm not sure what you mean by this. I can see 3 ways of handling
On 9 בפבר׳ 2015, at 02:04, Jordi Boggiano j.boggi...@seld.be wrote:
On 08/02/2015 23:24, Zeev Suraski wrote:
There's zero or virtually zero controversy surrounding the weak typing RFC,
the one that was v0.1. The controversy wasn't (and isn't) about what was in
v0.1, but rather, about what
Hey:
On Mon, Feb 9, 2015 at 10:40 AM, Pierre Joye pierre@gmail.com wrote:
hi,
Should we push json_parser.tab.c? Which is generated (re2c), just like
what is done in date or other?
I think we should, and also use a better name...(.tab.c?)
thanks
Cheers,
--
Pierre
@pierrejoye |
Hi all,
On Mon, Feb 9, 2015 at 3:41 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Mon, Feb 9, 2015 at 2:12 PM, Daniel Lowrey rdlow...@gmail.com wrote:
First, let me say that I have voted against the current scalar types RFC.
Please do not let that color your evaluation of the rest of this
Hey:
On Mon, Feb 9, 2015 at 5:06 AM, Jan Ehrhardt php...@ehrhardt.nl wrote:
Rasmus Lerdorf in php.internals (Thu, 05 Feb 2015 17:28:37 -0500):
We have had quite a number of changes to the extension API and it
worries me a little bit how long it will take everyone to get their
extensions ported.
Hi Maciej,
On Mon, Feb 9, 2015 at 1:48 PM, Maciej Sobaczewski so...@php.net wrote:
I'm totally aware that those files are tend to be more up-to-date thanks
to placing them directly where core developers work. However, we have wiki
pages for internals stuff, so why not move it to the manual
On 08/02/2015 20:33, Zeev Suraski wrote:
FWIW, while I think strict types - stricter than even strict languages -
don't belong in PHP, this syntax is clearly a step up from declare(), which
was definitely not intended for this purpose.
I'm kind of intrigued what purpose it *was* intended for.
hi,
On Mon, Feb 9, 2015 at 2:44 AM, Andrea Faulds a...@ajf.me wrote:
Hi,
I’m posting this in a new thread since people might (reasonably) be ignoring
further responses to the [VOTE] thread.
I’m considering a small change to the Scalar Type Hints RFC, specifically
about syntax. Quite a
On 08/02/2015 23:24, Zeev Suraski wrote:
There's zero or virtually zero controversy surrounding the weak typing RFC,
the one that was v0.1. The controversy wasn't (and isn't) about what was in
v0.1, but rather, about what wasn't in there, namely, strict typing; Not in
the contents of the v0.1
On 09/02/15 00:05, Rowan Collins wrote:
Some of the new 'styles' of writing things are
going to make things considerably worse for those who are going to have
to maintain this code in the future.
If you're writing code that you know will be hard to maintain in the
future, you're doing
Hi!
Should we push json_parser.tab.c? Which is generated (re2c), just like
what is done in date or other?
I think we should, otherwise building from release package without re2c
would be impossible, and I think before it was possible. In any case, we
should be consistent - if we commit
On Sun, Feb 8, 2015 at 3:22 PM, Zeev Suraski z...@zend.com wrote:
I'm well aware of it as I wrote that policy. The goal of the policy was to
prevent a situation where a temporary majority can introduce features into
the language that would later on be impossible to reverse. It's not by any
Pierre Joye in php.internals (Mon, 9 Feb 2015 09:40:21 +0700):
Should we push json_parser.tab.c? Which is generated (re2c), just like
what is done in date or other?
Yes, you should. I ran into this problem when I tried to compile PHP7
from git head. The Windows builds are currently broken:
On Mon, Feb 9, 2015 at 11:10 AM, Xinchen Hui larue...@php.net wrote:
Hey:
On Mon, Feb 9, 2015 at 10:40 AM, Pierre Joye pierre@gmail.com wrote:
hi,
Should we push json_parser.tab.c? Which is generated (re2c), just like
what is done in date or other?
I think we should, and also use a
Hi Daniel,
On Mon, Feb 9, 2015 at 2:12 PM, Daniel Lowrey rdlow...@gmail.com wrote:
First, let me say that I have voted against the current scalar types RFC.
Please do not let that color your evaluation of the rest of this message
...
I want to go on record (for the n-th time) as being
Hi Guilherme,
On Mon, Feb 9, 2015 at 1:44 PM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Class invariants could be done as this example:
class Foo {
private function isValidState() {
// Checks class's state and returns boolean
}
public function
Hey:
On Mon, Feb 9, 2015 at 1:44 PM, Pierre Joye pierre@gmail.com wrote:
On Mon, Feb 9, 2015 at 11:10 AM, Xinchen Hui larue...@php.net wrote:
Hey:
On Mon, Feb 9, 2015 at 10:40 AM, Pierre Joye pierre@gmail.com wrote:
hi,
Should we push json_parser.tab.c? Which is generated (re2c),
Hi Zeev,
On 8 Feb 2015, at 23:24, Zeev Suraski z...@zend.com wrote:
It's not stretching the truth or even slightly bending it, considering the
RFC currently being voted on is a superset of that RFC.
That has no relevancy.
There's zero or virtually zero controversy surrounding the weak
2015-02-09 1:48 GMT+02:00 Rowan Collins rowan.coll...@gmail.com:
On 08/02/2015 22:48, S.A.N wrote:
Hi internals.
I really hope that in the future PHP 7, there will be new server API.
May be you interested to know about them, here is the link, I am not
the author of development:
hi,
Should we push json_parser.tab.c? Which is generated (re2c), just like
what is done in date or other?
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Feb 9, 2015 10:29 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Matt and all,
On Mon, Feb 9, 2015 at 6:52 AM, Matt Parker m...@lamplightdb.co.uk
wrote:
The first question was 'Did you read the RFC' and the second 'Would
you like the RFC to
pass'. I set it up Friday morning (GMT) and
So, controversy is where a lot of people disagree - and there were
numerous
people in the original thread who disagreed with the RFC and preferred
strict
types. I actually tallied them in a reply to Zeev (which I later quoted in
a reply
to Andi). There were almost as many people against the
On 9 בפבר׳ 2015, at 01:45, Andrea Faulds a...@ajf.me wrote:
Hi Zeev,
On 8 Feb 2015, at 23:24, Zeev Suraski z...@zend.com wrote:
It's not stretching the truth or even slightly bending it, considering the
RFC currently being voted on is a superset of that RFC.
That has no relevancy.
On Mon, Feb 9, 2015 at 6:24 AM, Zeev Suraski z...@zend.com wrote:
So, controversy is where a lot of people disagree - and there were
numerous
people in the original thread who disagreed with the RFC and preferred
strict
types. I actually tallied them in a reply to Zeev (which I later quoted
On Mon, Feb 9, 2015 at 7:47 AM, Andrey Andreev n...@devilix.net wrote:
Hi,
On Mon, Feb 9, 2015 at 2:10 AM, Pierre Joye pierre@gmail.com wrote:
There is a vote, you do not like the RFC or part of
it, vote no. But this constant attempt to get exactly what you want
and do almost everything
Hi Matt and all,
On Mon, Feb 9, 2015 at 6:52 AM, Matt Parker m...@lamplightdb.co.uk wrote:
The first question was 'Did you read the RFC' and the second 'Would
you like the RFC to
pass'. I set it up Friday morning (GMT) and tweeted it around a bit
(I have a grand total
of 58 followers on
On Mon, Feb 9, 2015 at 2:48 PM, Jan Ehrhardt php...@ehrhardt.nl wrote:
Pierre Joye in php.internals (Mon, 9 Feb 2015 09:40:21 +0700):
Should we push json_parser.tab.c? Which is generated (re2c), just like
what is done in date or other?
Yes, you should. I ran into this problem when I tried to
On 09/02/2015 00:05, Andrea Faulds wrote:
Secondly, it is less specific than the current proposal - it suggests that PHP has a generic
strict mode, rather than a strict type-checking mode.
It could be renamed to strict_types, but that loses some elegant.
Would more strict features be added
Hi Yasuo,
Design by Contract could be used at the top of Annotation if (and only if)
it also had support for Interceptors. Since it could potentially be a
nightmare for PHP, I don't think it's time to propose something at the top
of another thing that is still far from being reality.
It would
Hi Guilherme,
On Mon, Feb 9, 2015 at 11:58 AM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Design by Contract could be used at the top of Annotation if (and only if)
it also had support for Interceptors. Since it could potentially be a
nightmare for PHP, I don't think it's
Hi Yasuo,
Class invariants could be done as this example:
class Foo {
private function isValidState() {
// Checks class's state and returns boolean
}
public function doSomething($args) {
// Some complex operation over Foo instance using $args
// then...
1 - 100 of 108 matches
Mail list logo
