Hi all, Zend engine experts especially,
On Mon, Feb 23, 2015 at 6:23 AM, Yasuo Ohgaki wrote:
> I wrote patch and made adjustment in the RFC
> https://wiki.php.net/rfc/script_only_include
> https://github.com/php/php-src/pull/
> Where to check filename extension is subject to be changed.
> At
Hi Levi,
On Mon, Feb 23, 2015 at 3:40 PM, Levi Morrison wrote:
> Aside from the new warning that is emitted and the old one that is
> removed no other behavior is changed. This means the "bug" will remain
> through the PHP 7 lifecycle even if this RFC passes. If the RFC passes
> the colliding co
On Sun, Feb 22, 2015 at 11:33 PM, Yasuo Ohgaki wrote:
> Hi Levi,
>
> On Mon, Feb 23, 2015 at 1:39 PM, Levi Morrison wrote:
>>
>> I have moved the RFC for removing PHP 4 constructors[1] into voting
>> phase. As there are a lot of RFCs in discussion and voting right now I
>> will leave this RFC in
Hi Levi,
On Mon, Feb 23, 2015 at 1:39 PM, Levi Morrison wrote:
> I have moved the RFC for removing PHP 4 constructors[1] into voting
> phase. As there are a lot of RFCs in discussion and voting right now I
> will leave this RFC in voting phase until the evening (UTC-7) of March
> 6th which is 12
Hi Nikita,
On Mon, Feb 23, 2015 at 7:30 AM, Nikita Popov wrote:
> 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 which type of err
Hi,
For those interested in evaluating the impact of ZPP ruleset modications on
internal and userland code, A pull request is now available :
https://github.com/php/php-src/pull/1110
Please note that this is not a mere implementation of the RFC ruleset, although
it comes preconfigured this way
Dear Internals,
I have moved the RFC for removing PHP 4 constructors[1] into voting
phase. As there are a lot of RFCs in discussion and voting right now I
will leave this RFC in voting phase until the evening (UTC-7) of March
6th which is 12 days away; this will hopefully allow everyone to be
able
add me
Gopal Sharma
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi internals,
I came really close to reach the final state of my to be proposed "private
class, interface and trait" support here.
However, I have a bug under this circumstance:
https://gist.github.com/guilhermeblanco/3392925014c9f8374acc
I'd love if someone could give me a hand on how could I ge
Hi Dmitry and Nikita,
On Mon, Feb 23, 2015 at 6:23 AM, Yasuo Ohgaki wrote:
> I wrote patch and made adjustment in the RFC
> https://wiki.php.net/rfc/script_only_include
> https://github.com/php/php-src/pull/
> Where to check filename extension is subject to be changed.
> At first, I thought
Hi Stas,
On Mon, Feb 23, 2015 at 7:00 AM, Stanislav Malyshev
wrote:
> > I think this will be the final discussion before vote.
> > This RFC is to make PHP stronger against script inclusion attacks just
> like
> > other languages.
> >
> > https://wiki.php.net/rfc/script_only_include
>
> I still t
On 02/22/2015 10:06 PM, Zeev Suraski wrote:
One key premise behind both strict type hinting and coercive type hinting is
that conversions that lose data, or that 'invent' data, are typically
indicators of a bug in the code.
You're right that there's no risk of a segfault or buffer overflow from
Hi Lester,
I am not sure I understand well, but the extended type syntax partially
described in https://wiki.php.net/rfc/dbc may correspond to what you describe.
Such extended syntax will be part of 'Design by Contract', meaning it's
potentially too slow to run in production and checks can be t
Zeev,
> So the code after the fix would look like this:
> function foo(int $int): int {
> return $int + 1;
> }
>
> function bar(int $something): int {
> $x = (int) $something / 2; // (int) or whatever else makes it clear
> it's an int
> return foo($x);
> }
> ?>
>
> Let me explain how
Hi!
> How is coercive much smarter? Basically what coercive would do is
It can accept 2.0 but not 2.5. Explicit cast is a sledgehammer - it
would convert both to 2.
> How casting (int) could be such dangerous thing? Lets take for example
> this code:
>
> echo (int) "whats cooking!";
> echo int
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Monday, February 23, 2015 3:43 AM
> To: Stanislav Malyshev
> Cc: Zeev Suraski; Jefferson Gonzalez; PHP internals
> Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
> RFC)
>
> Stas,
>
>
Hi!
> It rejects code because doing code generation on the dynamic case is
> significantly harder and more resource intensive. Could that be built
> in? Sure. But it's a very significant difference from generating the
> static code.
I can appreciate that. Dynamic typing is hard to translate into
> -Original Message-
> From: Jefferson Gonzalez [mailto:jgm...@gmail.com]
> Sent: Monday, February 23, 2015 3:58 AM
> To: Stanislav Malyshev; Anthony Ferrara
> Cc: Zeev Suraski; Jefferson Gonzalez; PHP internals
> Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
> RF
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Monday, February 23, 2015 3:21 AM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
> RFC)
>
> Zeev,
>
>
> >> Partially.
> >>
> >> The static ana
On 02/22/2015 09:15 PM, Stanislav Malyshev wrote:
We were talking about the case where the argument was even, you must
have missed that part. If the argument is not even, indeed both models
would produce the same error, no difference there. The only difference
in your model vs. dynamic model so f
Stas,
On Sun, Feb 22, 2015 at 8:35 PM, Stanislav Malyshev wrote:
> Hi!
>
>> The difference though is the journey. The static analyzer can reason
>> about far more code with strict types than it can without (due to the
>> limited number of possibilities presented at each call). So this
>> leaves t
Stas,
>> It is still a performance advantage, because since we know the types
>> are stable at compile time, we can generate far more optimized code
>> (no variant types, native function calls, etc).
>
> I don't see where it comes from. So far you said that your compiler
> would reject some code.
Hi!
> This makes it impossible to use this feature with some of the ext/std
> functions (array_udiff, array_interect_ukey, etc.) and just feels a bit
> incomplete...
I see how it can be useful with crazy functions like array_udiff, but
these are in tiny minority. What I am concerned about is that
Hi!
> The difference though is the journey. The static analyzer can reason
> about far more code with strict types than it can without (due to the
> limited number of possibilities presented at each call). So this
> leaves the dilema: compiled code that behaves slightly differently
> (what Recki d
Zeev,
>> Partially.
>>
>> The static analysis and compilation would be pure AOT. So the errors would
>> be told to the user when they try to analyze the program, not run it.
>> Similar
>> to HHVM's hh_client.
>
> How about that then:
>
> 1. The developers runs a static analyzer on the program.
>
Hi!
> It is still a performance advantage, because since we know the types
> are stable at compile time, we can generate far more optimized code
> (no variant types, native function calls, etc).
I don't see where it comes from. So far you said that your compiler
would reject some code. That doesn
On 23/02/15 00:25, Anthony Ferrara wrote:
> And as the static analyzer traces back, if it finds possibilities that
> don't match (for example, if you assigned it directly from $_POST),
> it's able to say that either the original assignment or the function
> call is an error.
Why would using an int
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Monday, February 23, 2015 3:02 AM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
> RFC)
>
> Zeev,
>
> > I think we are indeed getting somewher
Zeev,
> I think we are indeed getting somewhere, I hope.
> If I understand correctly, effectively the flow you're talking about in your
> example is this:
>
> 1. The developers tries to run the program.
> 2. It fails because the static analyzer detects float being fed to an int.
> 3. The user chan
Silly question time again ...
Currently I have an array of variables and the docblock annotation tells
me just what each element is intended to be. I process the variables on
that basis and while it may be helpful to have some higher level of
'restraint', I have a working flexible system. As a var
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Monday, February 23, 2015 2:25 AM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
> RFC)
>
> Ze'ev,
It's Zeev, thanks :)
> Because strict typ
Ze'ev,
On Sun, Feb 22, 2015 at 6:57 PM, Zeev Suraski wrote:
>> -Original Message-
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Monday, February 23, 2015 1:35 AM
>> To: Zeev Suraski
>> Cc: PHP internals
>> Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type
Hi, Stas
2015-02-22 19:20 GMT-03:00 Stanislav Malyshev :
> Hi!
>
> I like the idea. But we need to examine the cases carefully so we don't
> block some future routes - especially this is with regards to such
> things as type names which we wanted to reserve.
>
> I.e. method names resolution is pr
Stas,
On Sun, Feb 22, 2015 at 6:47 PM, Stanislav Malyshev wrote:
> Hi!
>
>> You can tell because you know the function foo expects an integer. So
>> you can infer that $x will have to have the type integer due to the
>> future requirement. Which means the expression "$something / 2" must
>> also
On 02/22/2015 06:28 PM, François Laupretre wrote:
Hi Stas,
It seems the actual problem is that we have too many compiler / code analysis
experts in the community ;)
(don't get me wrong, I am not saying that for you, I just admire your patience
explaining the same again and again to people who
On 02/22/2015 06:28 PM, François Laupretre wrote:
Hi Stas,
It seems the actual problem is that we have too many compiler / code analysis
experts in the community ;)
(don't get me wrong, I am not saying that for you, I just admire your patience
explaining the same again and again to people who
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Monday, February 23, 2015 1:35 AM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
> RFC)
>
> Zeev,
>
> >> And note that this can only work with
Can you all of you stop this madness with moving discussions off list?
It is detestable, against almost all openness and principles behind an oss
project like php. If we can't discuss anymore design, plans, ideas etc on
the list then we are doomed, for good.
On Feb 22, 2015 3:49 PM, "Anthony Ferra
Adding in a thread that was started in private, but absolutely is
worth sharing with the group:
-- Forwarded message --
From: Etienne Kneuss
Date: Sun, Feb 22, 2015 at 8:42 AM
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
To: Zeev Suraski
Cc: Anthony Ferrara , Dmitry Sto
Hi!
> You can tell because you know the function foo expects an integer. So
> you can infer that $x will have to have the type integer due to the
> future requirement. Which means the expression "$something / 2" must
> also be an integer. We know that's not the case, so we can raise an
> error her
Zeev,
>> And note that this can only work with strict types since you can do the
>> necessary type inference and reconstruction (both forward from a function
>> call, and backwards before it).
>
> Please do explain how strict type hints help you do inference that you
> couldn't do with dynamic typ
Anthony,
I started writing this long response, but instead, I want to localize the
whole discussion to the one true root difference. Your position on that
difference is the basis for your entire case, and my position on this
argument is the base for my entire case.
There we go:
> And note that
Hi!
> I do not see much gain today to "improve" them while I do not see why we
> should not. It does not hurt.
The gain is simple - today, assertions have costs so people that are
performance-conscious (rightly or wrongly) use them less than they
could. We can make them cost-less in production, w
Stas,
>>> -- Can the code generated for a strict type hint can somehow be optimized
> significantly better than the code generated for a dynamic/coercive type
> hint.
>> And me, who wrote an AOT compiler that does **exactly** this, claim
>
> Sorry, did exactly what? Here a bit more explanation wou
On 22/02/15 22:30, Nikita Popov wrote:
> 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 which type of error should
> be thrown, I'm
Hi!
>> -- Can the code generated for a strict type hint can somehow be optimized
significantly better than the code generated for a dynamic/coercive type
hint.
> And me, who wrote an AOT compiler that does **exactly** this, claim
Sorry, did exactly what? Here a bit more explanation would help.
>
Zeev,
On Sun, Feb 22, 2015 at 1:37 PM, Zeev Suraski wrote:
>> -Original Message-
>> From: Jefferson Gonzalez [mailto:jgm...@gmail.com]
>> Sent: Sunday, February 22, 2015 4:25 PM
>> To: Etienne Kneuss; Anthony Ferrara; Zeev Suraski
>> Cc: PHP internals
>> Subject: Re: [PHP-DEV] Coercive Sc
Hi!
> Well, strict on a JIT environment may haven't been proved, but it surely
> has been proved on statically compiled languages like C. Currently, a
I understand that using the same concept of typing in both cases can be
confusing, but that's pretty much where the similarity ends. Strict
typing
> -Original Message-
> From: Jefferson González [mailto:jgm...@gmail.com]
> Sent: Sunday, February 22, 2015 11:59 PM
> To: Stanislav Malyshev
> Cc: Etienne Kneuss; Anthony Ferrara; Zeev Suraski; PHP internals
> Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> 2015-02-22 16:38 GMT-0
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 which type of error should
be thrown, I'm mainly going by what category other s
Hi Stas,
It seems the actual problem is that we have too many compiler / code analysis
experts in the community ;)
(don't get me wrong, I am not saying that for you, I just admire your patience
explaining the same again and again to people who never read one line from PHP
core source).
Regard
Hi!
> I see a LOT of "no" votes against this RFC but can't find the thread
> outlining the reasoning for such resistence.
I think my attempts to explain that this was a step towards named
params, not a contradiction with them, failed - people read it, say "we
understood it" and the say "no, we do
On 22/02/15 18:37, Zeev Suraski wrote:
> Variant* calc(Variant& val1, Variant& val2) {
>if(val1.isInt() ) {
> // type checking
> if (!val1.coerceToInt()) {
> throw new RuntimeError()
> }
> If (!val2.coerceToInt()) {
> throw new RuntimeError();
Hi!
> RFC: https://wiki.php.net/rfc/context_sensitive_lexer
> TL;DR commit: https://github.com/marcioAlmada/php-src/commit/c01014f9
> PR: https://github.com/php/php-src/pull/1054
I like the idea. But we need to examine the cases carefully so we don't
block some future routes - especially this is
> -Ursprüngliche Nachricht-
> Von: Pavel Kouřil [mailto:pajou...@gmail.com]
> Gesendet: Sonntag, 22. Februar 2015 22:18
> An: Robert Stoll
> Cc: Zeev Suraski; PHP internals
> Betreff: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> On Sun, Feb 22, 2015 at 9:42 PM, Robert Stoll wrote:
> >
Hi Robert,
> So what does that mean for scalar types?
> IMO it means that way more important than adding scalar type hints to PHP
> 7.0 is to agree on a new set of conversion rules for the long run. PHP should
> strive to have one consistent set of conversion rules which apply in all
> places
> w
Hi Anatol,
On Sun, Feb 22, 2015 at 6:09 PM, Anatol Belski
wrote:
>
>
> FYI I had to downgrade re2c to 0.13.6 as the latest randomly crashes.
Ok. :) There are no differences in the generated DFA so it's not a problem
for me to use 0.13.6 too.
The preferred versions are more about nicer diffs wh
Hi!
> I think this will be the final discussion before vote.
> This RFC is to make PHP stronger against script inclusion attacks just like
> other languages.
>
> https://wiki.php.net/rfc/script_only_include
I still think this RFC takes a wrong road for the following reasons:
1. Having any code
2015-02-22 16:38 GMT-04:00 Stanislav Malyshev :
> Yes, that's not the case, at least nobody ever showed that to be the
> case. In general, as JS example (among many others) shows, it is
> completely possible to have JIT without strict typing. In particular,
> coercive typing provides as much infor
Hi all,
I wrote patch and made adjustment in the RFC
https://wiki.php.net/rfc/script_only_include
https://github.com/php/php-src/pull/
Where to check filename extension is subject to be changed.
At first, I thought implementing this as PHP code is good, but
I've changed my mind. It seems bette
On Sun, Feb 22, 2015 at 9:42 PM, Robert Stoll wrote:
>
> Probably it is a philosophical question how to look at it. IMO the only
> difference in C# (as well as in Java) lies in the way the conversions are
> applied. Implicit conversions are applied automatically by the compiler where
> explicit
Hi Matteo,
On Sun, Feb 22, 2015 at 7:45 PM, Matteo Beccati wrote:
> The default behaviour of mysql/pgsql drivers is to convert to the matching
> PHP type, if possible. That can be turned off via
> PDO::ATTR_STRINGIFY_FETCHES => true.
>
> If PDO_DBLIB doesn't behave like that, I'd say it's a bug
> -Ursprüngliche Nachricht-
> Von: Pavel Kouřil [mailto:pajou...@gmail.com]
> Gesendet: Sonntag, 22. Februar 2015 20:02
> An: Robert Stoll
> Cc: Zeev Suraski; PHP internals
> Betreff: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> On Sun, Feb 22, 2015 at 7:30 PM, Robert Stoll wrote:
>
Hi!
> A JIT or AOT machine code generator IMHO will never have a decent use of
> system resources without some sort of strong/strict typed rules,
> somebody explain if thats not the case.
Yes, that's not the case, at least nobody ever showed that to be the
case. In general, as JS example (among m
2015-02-22 14:37 GMT-04:00 Zeev Suraski :
> I think it's fair to say that Dmitry - who led the PHPNG effort - cares *a
> lot* performance. I'm sure you'd agree. I tend to think that I also care
> a lot about performance, and so does Xinchen. We all spent substantial
> parts of our lives working
[I hope I managed to get the threading right although I think it's more
than likely I didn't; apologies in advance if that's the case]
> -Original Message-
> From: Joe Watkins [mailto:pthre...@pthreads.org]
> Sent: Sunday, February 22, 2015 5:07 PM
> To: Jefferson Gonzalez
> Cc: Etienne K
On 02/22/2015 11:06 AM, Joe Watkins wrote:
This is an inescapable difference, of the the kind that definitely does
have a negative impact on implementation complexity, runtime, and
maintainability.
To me, it only makes sense to compile strict code AOT or JIT; If you want
dynamic behaviour, we h
On Sun, Feb 22, 2015 at 7:30 PM, Robert Stoll wrote:
> Hi Pavel,
>
> Yes, I am suggesting to make conversions behave the same regardless if it is
> implicit or explicit. The only difference between the two should be that one
> is stated explicitly by the user where the other is applied implicitl
> -Original Message-
> From: Jefferson Gonzalez [mailto:jgm...@gmail.com]
> Sent: Sunday, February 22, 2015 4:25 PM
> To: Etienne Kneuss; Anthony Ferrara; Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
Jefferson,
Please note that Anthony, the le
Hi Pavel,
> -Ursprüngliche Nachricht-
> Von: Pavel Kouřil [mailto:pajou...@gmail.com]
> Gesendet: Sonntag, 22. Februar 2015 15:54
> An: Robert Stoll
> Cc: Zeev Suraski; PHP internals
> Betreff: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> On Sun, Feb 22, 2015 at 2:09 PM, Robert Stoll
On Thu, Feb 19, 2015 at 4:13 PM, Dmitry Stogov wrote:
> Hi Nikita,
>
> I refactored your implementation: https://github.com/php/php-src/pull/1095
>
> I introduced a class hierarchy to minimize effect on existing code.
> cacth (Exception $e) won't catch new types of exceptions.
>
> BaseException (
Hi Jakub,
On Tue, February 17, 2015 17:53, Anatol Belski wrote:
> Hi Jakub,
>
>
> On Sun, February 15, 2015 21:18, Jakub Zelenka wrote:
>
>> On Wed, Feb 11, 2015 at 11:56 AM, Jakub Zelenka wrote:
>>
>>
>>>
>>>
>>> I would like to push the the bison tab files shortly as the majority
>>> of people
> 1. Does weak mode could provide the required rules to implement a JIT
with a sane level of memory and CPU usage?
There is no objective answer to the question while it has the clause "with
a sane level of ...".
The assertion in the RFC that says there is no difference between strict
and weak typ
On Sun, Feb 22, 2015 at 2:09 PM, Robert Stoll wrote:
>
> I see the migration plan roughly as follows:
>
> PHP 7.0:
> - reserve keywords: bool, int, float including alternatives
> - deprecate alternative type names such as boolean, integer etc.
>
> - introduce new conversion functions which r
On 02/22/2015 09:00 AM, Etienne Kneuss wrote:
There have been several attempts:
for JS: http://users-cs.au.dk/simonhj/tajs2009.pdf
or similar techniques applied to PHP, quite outdated though:
https://github.com/colder/phantm
You are right that the lack of static information about types is (one
On 22/02/2015 13:09, Robert Stoll wrote:
[snip]
...
PHP 7.1: necessary bug-fixes introduced with PHP 7.0
PHP 7.x: deprecate even more if required
PHP 8:
- introduce scalar type hints which reflect the conversion rules as defined (adding
strict type hints as well is possible of course, wheth
From: Etienne Kneuss [mailto:col...@php.net]
Sent: Sunday, February 22, 2015 3:00 PM
To: Anthony Ferrara; Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
> The question is rather: at what weight should we take (potential/future)
> external tools into account w
Hi Zeev,
> -Ursprüngliche Nachricht-
> Von: Zeev Suraski [mailto:z...@zend.com]
> Gesendet: Samstag, 21. Februar 2015 18:22
> An: PHP internals
> Betreff: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> All,
>
>
>
> I’ve been working with François and several other people from internals@
On Sat Feb 21 2015 at 21:08:39 Anthony Ferrara wrote:
> Zeev,
>
> I won't nit-pick every point, but there are a few I think need to be
> clarified.
>
> >> > Proponents of Dynamic STH bring up consistency with the rest of the
> >> language, including some fundamental type-juggling aspects that hav
"Pierre Joye" wrote in message
news:CAEZPtU7vt=ppk4p3vfzflaepzi_wfr2hr_av+dtzvd6d2dz...@mail.gmail.com...
On Feb 21, 2015 2:08 AM, "Tony Marston" wrote:
""Nikita Nefedov"" wrote in message news:op.xuco5eutc9evq2@nikita-pc...
On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston
wrote:
I
On 21/02/2015 23:12, Yasuo Ohgaki wrote:
Hi Adam,
On Sat, Feb 21, 2015 at 2:22 AM, Adam Baratz wrote:
This driver returns all column data as a string, regardless of how it's
represented in the DB. I created a patch for my own use that syncs up the
type handling with the behavior of the MSSQL
Apologies for terribly formatted communication there.
Cheers
Joe
On Sun, Feb 22, 2015 at 10:38 AM, Michael Wallner wrote:
>
> > On 22 02 2015, at 11:31, Lester Caine wrote:
> >
> > With the discussion on adding http extension by default and not now
> > having other key extensions in a normal b
> I see no reason
why those who want 'strict' can't have that as a pecl module to replace
'lax' operations.
Simple, the most robust implementation is inferior to internal support.
Making a call to this:
function (int $some, double $other) {
}
behave as if Zend is strict is quite easy, what is
> On 22 02 2015, at 11:31, Lester Caine wrote:
>
> With the discussion on adding http extension by default and not now
> having other key extensions in a normal build I'm looking at what I NEED
> and what I can get away without. On the current PHP7 test build I do not
> have mysqlnd installed as
With the discussion on adding http extension by default and not now
having other key extensions in a normal build I'm looking at what I NEED
and what I can get away without. On the current PHP7 test build I do not
have mysqlnd installed as I don't use mysql, but I can't make the mysql
section avail
On Sat, Feb 21, 2015 at 2:39 PM, Pavel Kouřil wrote:
> On Sat, Feb 21, 2015 at 11:25 PM, Zeev Suraski wrote:
> > There’s a fundamental difference between the two RFCs that goes beyond
> > whether using a global INI setting and the other per-file setting. The
> > fundamental difference is that t
On 02/21/2015 09:10 PM, Pádraic Brady wrote:
>
> On the RFC rules themselves, a few comments:
>
> 1. Happy to see leading/trailing spaces excluded.
> 2. Rules don't make mention of leading zeroes, e.g. 0003
> 3. "1E07" might be construed as overly generous assuming we are
> excluding stringy int
87 matches
Mail list logo
