Hi!
> What I found *safe*, with checkers that check object is properly
> initialized, so not needing patch, but throwing exceptions or warnings
> when used bad constructed :
> - SPL
SPL unfortunately is not safe at all - a lot of iterator classes
segfault on no-ctor initialization. I'll make a pa
Hi!
> What I found *not safe*, throwing unwanted warnings hitting an
> undesired behavior, or even segfaulting, and thus needing patch :
> - Dom
> - Mysqli
> - sqlite3 (sqlite3stmt class segfaults)
I'm testing a patch for sqlite3 right now and will commit it shortly,
but I could not reproduce an
Hi!
> Could somebody please clarify what issues are still open here? From what
> I understand, both the opcache issue and the recursion issue are fixed
> now. What's the discussion about?
As I understand, the issue is that if you define class constant like this:
class Foo { const Bar = [0]; }
e
Hi!
> nope, some mock frameworks do that (afair atoum for example) but
> phpunit(phpunit-mock-objects to be more precise) was using the serialize
> trick and newInstanceWithoutConstructor()
> (https://github.com/sebastianbergmann/phpunit-mock-objects/blob/42f29d650744fd7ce785e7a4dd3598a09b0bfd2b/s
Hi!
> yeah, that would work ofc, but as these libs seems to have instanitate
> arbitrary classes, that would require either generating files on the fly
> and including them or simply evaling them, but of those are a bit
> dirtier than using Reflection for the same job.
True but that's what phpun
Hi!
> All right, looks like it is my fault not making the reply sounds
> critical enough. It pretty much make all third party php-litespeed rpms
> useless, only causes trouble and confusion for LiteSpeed users.
I'm not sure what changed with the last php release - the old code was
there for a l
Hi!
> client) I see no reason to keep the limitation in
> the ReflectionClass::newInstanceWithoutConstructor() and allowing the
> instantiation of internal classes will provide a clean upgrade path to
> doctrine and co.
I think we should ensure the objects will be in safe (i.e. no-crashing)
state
Hi!
> The way voting works now, I happen to know which option is "winning". I
> happened to know that *before* I cast my vote. The current results are
> posted on the RFC, and the same information percolated into emails
> encouraging folks to vote. I wonder, though, if knowing which was "leading
Hi!
> I just found that my commits to PHP-5.4.31 and PHP-5.5.15 branch have
> been voided, the result is that in final 5.4.31 and 5.5.15 release
> package, sapi/litespeed code is still the ancient V5.5 release, it is
> ridiculous!
No, it is not ridiculous, it is the release process. The three-
Hi!
> The point of this RFC is to strike a compromise that is generally
> useful rather than helping one specific use case (strict hints) or
> another (casts).
What you call "compromise" is the inconsistency - it's not strict
typing, it's not weak typing, it's half that and half this without any
Hi!
> After consulting with Anthony about this, the RFC and patch have been
> updated to disallow booleans for int, float, numeric and string type
> hints. The conversions table now looks like this:
This makes very little sense, 0 means the same as false is in many
contexts in PHP and also in man
Hello!
The PHP development team announces the immediate availability of PHP 5.4.31.
Over 10 bugs were fixed in this release.
All users of PHP 5.4 are encouraged to upgrade to this release.
For source downloads of PHP 5.4.31 please visit our
downloads page: http://www.php.net/downloads.php
Wind
Hi!
> Big +1 on this. btw, a lot of folks on the HHVM team have been having
> trouble getting subcribed to lists.php.net, if I sent you a set of
> email addresses and lists, could you help out with some bulk
> subscriptions (including standards@)?
I guess that would be folks on syst...@php.net,
Hi!
> I would like to propose to use list stada...@lists.php.net (which has
> been dormant since 2009) for PHP spec work. What do you think?
Of course it's standa...@lists.php.net.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Dev
Hi!
I would like to propose to use list stada...@lists.php.net (which has
been dormant since 2009) for PHP spec work. What do you think?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: h
Hi!
> Progress is being made on getting it all into a collaborative format.
> Our documentation guy is currently favoring markdown as an initial
> format which is able to express everything currently in the spec, and
> he's planning to build some rendering scripts that'll be able to
> produce oth
Hi!
> I think it should behave like class arguments do.
That's called strict typing and was discussed many times. Do we really
want another round of repeating the same arguments?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Develop
Hi!
> It was a restriction to not support arrays in constant context. It seems
> like nobody can remember why it was introduced.
My vague recollection is that it had some troubles with keeping
refcounts consistent, esp. withing bytecode caching context, but it may
be a false memory :)
> However,
Hi!
> Another idea would be a Git repository with the specification as
> markdown files. This would allow creating Pull Requests via GitHub.
I think facilitating discussion and feedback is more important than
change tracking for now, but given github also has issues facility it
may actually work.
Hi!
>> > class Foo {
>>const BAR = [0];
>>static $a = Foo::BAR; // constant array usage
>> }
>> var_dump(Foo::$a); // prints array
>> var_dump(Foo::BAR); // emits fatal error
>> ?>
>
> They can only be used in static scalar contexts.
>
> I wanted to introduce constants to be used an
Hi!
> As we’re getting closer to release 5.6.0, and given the very high
> level of interest in phpng, I think it’s time for us to provide some
> clarity regarding what happens post 5.6.0.
>
> Dmitry and I wrote an RFC proposing that we merge phpng into master
> and turn it into the basis of the n
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
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
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!
> 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!
>
> What would be a better term? Optional strict typing in function and
> method signatures?
Parameter typing, or typed parameters if you will. One of the options,
of course, there could be many others.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP
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/730
That lis
Hi!
> As discussed in previous threads about this failure, we (doctrine) can
> move away from the `unserialize()` hack if
> `ReflectionClass#newInstanceWithoutConstructor()` provides support for
> internal classes.
Could you explain why it is needed to instantiate internal classes
without calling
Hi!
> * Time (actually pretty common in web apps, though we have a DateTime
> class)
Admittedly, we're getting closer to the dreaded year 2038, but what does
it actually mean to divide current Unix timestamp by 3 and why one would
ever want to do this? We also have classes for real datetime calcu
Hi!
> IMHO this isn't something we should change in a 2nd digit release, but on a
> major version, even if it wasn't documented.
We don't have much option here. Keeping it leads to a remote triggerable
segfaults. We've discussed this here just recently. This is a hack that
does not work properly
Hi!
> in such case, the serialized data could be shared by 5.5 and 5.6...
This is true, but what you presented is not serialized data. Serialized
data will be fine. But the code you shown instead tries to use
serializer as a roundabout way of instantiating objects. This is not the
right thin
Hi!
> There are really only two levels of error IMO, those that are log
> file messages (silenced or no), and those that actually stop the
> script unless handled. I worry about making E_CAST the former but
> allowing people to make it the latter, because then people would and
> suddenly code rely
Hi!
> E_CAST is problematic. Having something we encourage some people to
> make an error and some people not to means that in some cases your
> library works fine and rosy in other people’s environments and
> sometimes it crashes your app. This is *not good*. We must not
> encourage people to mak
Hi!
> The problem with making this RFC do the lossy thing is it then
> removes one key advantage of it: that this RFC provides a measure of
> strictness. Without that, we have no real compromise proposal, and we
> might as well introduce a second set of “strict” type hints. The
> whole point of th
Hi!
> As has been pointed out already, that would be inconsistent with
> existing type hints. zend_parse_parameters emits E_WARNING and
> returns FAILURE, while type hints raise E_RECOVERABLE_ERROR. To make
> scalar type hints not emit E_RECOVERABLE_ERROR and instead do
> something weaker would in
Hi!
> That's only a problem if you frame the new hints as "a type of implicit
> cast". If they were to be described in relation to existing
> functionality, I'd describe them as a new type of *explicit* cast, but
How they are explicit cast if you're not explicitly casing anything?
> as mentio
Hi!
> The PHP community that I know, wants to have _both_ type cast hinting
> and strict type declarations.
No, different members of the community want different options, because
it would serve their particular use cases. But that does not mean it
necessarily must be part of PHP - not all use cas
Hi!
> The answer - which is definitely a matter of opinion - is that allowing
> any string reduces the usefulness of the type hint.
IMO, having consistent rules is much more, orders of magnitude more
important than serving any particular use case. We will always have use
cases in which any parti
Hi!
> On the other hand, this RFC proposes a set of type hint casts which
> have stricter rules than an explicit cast, and also somewhat stricter
> than zend_parse_parameters, meaning that people can safely do
> $_GET[‘thing’] and it’ll work, but if a nonsensical value is passed
> in, the program
Hi!
> Both of those are likely not to be installed on most systems. Why do
Why not? bcmath is in core since forever and has no external
requirements, gmp builds practically everywhere too. AFAIR all distros
have it.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
Hi!
> It elaborates a little more, so I’d suggest reading it first. What
> are your thoughts? I think this is a simple and obvious addition.
INT_MAX is kind of an edge case, if you need arbitrary-length precision
you can always use gmp or bcmath. I'm not sure this one-off use case
that is already
Hi!
> I would have expected 1 - since it appears, from the code, that $a should
> only contain integers.
Until the time you changed it. If you write:
function foo(SplFileInfo $a) {
$a = 3 / 2;
}
Would you somehow expect $a to magically conjure SplFileInfo object out
of 3/2?
--
Stan
Hi!
>> cast to them, sure, because PHP as a rule allows you to cast anything to
>> anything explicitly (bar resources), but I can't, for example, do a
> loose
>> comparison between an array and a string.
>
> Exactly, that's my point. While you can explicitly cast scalars to arrays
> and even obj
Hi!
> In general, I am not in favour of casting typehints, as it would be a
> different behaviour from the hard-check typehints that we already have
> for classes and arrays.
It already is. All internal functions behave this way.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.
Hi!
> I suggested on IRC that empty strings, TRUE, FALSE, NULL, and values
> that validate for the int type hint could be accepted. Is that a good
> idea? Though it feels a bit loose, I think it covers all the
> important common use cases.
Then you need to make all internal functions that accept
Hi!
> That is exactly what is being proposed though. People (including
> Anthony himself, along with other proposals) have previously
> suggested type hints which just casted. However, I don’t think this
> is terribly useful. You can already do that really easily (`$foo =
> (int)$foo;`), and it’s
Hi!
> One of the issues with the RFC as it stands is how to handle bool
> casting. While int, float and string only allow lossless casting
> (with the exception of objects, but we can’t really do anything about
> that), bool’s behaviour at the moment is quite different. I don’t
> think it makes se
Hi!
> PHP’s type hinting system is rather incomplete as it does not support
> scalars, only arrays, callables and objects. In 2012, Anthony Ferrara
> created an RFC which proposed type hinting for scalar types (int,
> float, bool, string and resource) with casting, with behaviour nearly
> the same
Hi!
> mentioned a few times now), and I think this will cause a significant
> amount of pain for the people who wanna merge pull requests after the
> phpng (or other similar major rewrite) is merged to the master, as they
> will be required to backport the changes.
When we will have the major rew
Hi!
> And while I was trying to figure out what does that mean, or why should
> that prevent the travis build, I've just remembered that we don't allow
> travis builds for PHP-5.3 and PHP-5.4 branches:
> http://git.php.net/?p=php-src.git;a=blob;f=.travis.yml;h=f1a333adcb3e6c35f3fe19c27fbd7a28d99fe
refer to the NEWS file:
https://github.com/php/php-src/blob/php-5.4.31RC1/NEWS
Please test it carefully, and report any bugs in the bug system.
The release is planned in 2 weeks, July 24th, if no critical issues will
be discovered in the RC.
Regards,
Stas Malyshev
PHP 5.4 RM
--
PHP
Hi!
> I added a CONCURRENCY_GROUP section, see
> https://github.com/m6w6/php-src/compare/parallel-run-tests?expand=1
>
> If the next test to execute is in the same CONCURRENCY_GROUP as one
> which is already/still running, it will be pushed back.
>
> So tests with f.e. listening servers could u
Hi!
> Having thought a bit about the subject, the heuristic I came up with was to
> 1) do not run tests from the same extension in parallel, and 2) do not run
> tests from certain extensions in parallel (e.g., mysql and pdo_mysql).
How about making it a whitelist? For tests/extensions we know i
Hi!
> Commit:7c2489751cc48961487edd69b49083d4ca6b4828
> Author:Sara Golemon Mon, 7 Jul 2014 12:19:11
> -0700
> Parents: 888fb3323ed1bb728064f27a6127d194eb92f9ee
> Branches: master
>
> Link:
> http://git.php.net/?p=php-src.git;a=commitdiff;h=7c2489751cc48961487edd69b490
Hi!
> Not any that I'm aware of, and I personally have never used is_null().
> I share your opinion that we don't really need is_null(), but with BC
> in mind, I don't think it would get removed.
There's nothing to remove. Every type has is_* function, including null
type. If is_null() is offensi
Hi!
> Final comments anyone, before I commit next week?
It looks strange that we have to hardcode so many mimetypes in the code,
and doesn't sound a scalable solution. Can't we make it use data from
fileinfo or some other customizeable table so we don't have to keep all
MIME types hardcoded in th
Hi!
Looking at the patch, it converts zend_error_noreturn into
ZEND_IMPOSSIBLE, which is nothing in non-debug mode. This means code
that expected that execution ceases it this point (and jumps to a safe
bail-out point) now just continues in non-debug mode (probably causing
crash or memory corrupti
Hi!
> I think at some point you just need to go for "good enough" rather than
> "optimal support for everything". If we don't support the rather special
I am all for that. If only I wasn't this very minute bashed by several
other people for not accounting for every exotic use case and not
proposi
Hi!
> So what your saying, if I understand you correctly, is that PHP was
> intentionally designed to be non-deterministic? And it was designed that
> way to save a single character?
It is deterministic, there are rules for it, described in
http://us1.php.net/manual/en/language.namespaces.fallbac
Hi!
> I already have a mostly-working implementation for named arguments and
> unless I missed something critical it does not require us to redo
> argument passing. The idea I followed was to keep the argument passing
> pretty much as-is, just instead of always pushing on top of the stack to
> pla
Hi!
> I would not agree with your argument that it should be introduced because it
> is requested by real people for years and it is simple to add. Isn't that
> pretty much the same as "because we can"?
No, it is pretty much the opposite. It is "because people need it".
> IMO we should wait with
Hi!
> What I'm suggesting is simply a set of alternative functions to
> ip2long() and crc32() that return consistent values on all platforms,
> e.g. 32-bit signed integer values - a couple of new functions and a
> couple of quick updates to the documentation explaining why you might
> want to use
Hi!
> However I still wonder what prevents to finally implement named
> parameters too, it will provide the same feature while being even more
For named params, you need to rewrite all args handling, since now it is
a positional array and that doesn't work with named args. On the way
you'd have t
Hi!
> What would happen if I had done:
>
> define('default', 42);
>
> before that line?
Pretty much the same as if you did:
define('if', 42);
if($a == 1) print "one";
default is a keyword.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext.
Hi!
> The function names might look like this:
> - spl_register_autoloader -> autoloader for everything
Given we already have spl_autoload_register that'd be pretty confusing.
Also, we usually name functions in increasing order of specificity (i.e.
spl_autoload_call/spl_autoload_spl_autoload_func
Hi!
> I think this doesn't really help readability. Right now you should
> implement functions with many options with an $options array.
I don't understand. Who says I should do that? I certainly don't see how
I should.
> If we want to change something here, we should skip this step and go
> rig
Hi!
> another small advantage would be that IDEs could show you the default
> value for the argument when hovering the default keyword.
That actually would be excellent if they did it. I hope (if this is
accepted) everybody does.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sug
Hi!
> So the only case this effects is that you can't autoload a function from
> the same namespace that you're currently in without explicitly using
> that function.
>
> That's not such a huge issue.
I think it is such a huge issue, because this means this functionality
can not be used for rel
Hi!
> Yes, all of these problems can be solved - I am well aware of that. I am
> also painfully aware of how much time it can take to solve them reliably.
>
> I just would like to see a solution rather than a bunch of work-arounds -
> not for my own sake, my problem is solved, but for the sake of
Hi!
> Stas, does this problem still persist for you?
Yes, the test is still failing for me, and also seems to fail on Travis
periodically, see: https://travis-ci.org/php/php-src/builds/10751907
The output I'm getting is this:
Test
PHP 5.6.0-dev Development Server started at Mon Sep 2 07:49:11
Hi!
> I am not sure whether this is a little overhead.
>
> but if we do want this. to be honest, I even prefer leave it empty to
> "default".
>
> like create_query("delete=0", "name", , , true);
That's how it was initially, and I was convinced default is better. So I
don't think I'm going ba
Hi!
> namespace foo {
> use function biz\buz;
> use foo\bar;
>
> something(); // autoloaded as "something"
Wait, so it wouldn't work like class autoloader, using fully qualified
name? And autoloader would not then have any information about
namespaces, so you'd have to specify explic
Hi!
I've finally took some time to revive the skipping parameter RFC and
patch. For those who doesn't remember what it is please see:
https://wiki.php.net/rfc/skipparams
TLDR version:
The idea is to allow skipping parameters in function with optional
arguments so that this:
function create_que
Hi!
> there has been some chatter about windows.php.net, which drives me to
> the question: Do we need that site? Why and for what?
Since windows support in PHP is a bit different from Unix systems -
unlike all other systems, we provide official binaries - I think having
separate domain for it is
Hi!
> As far as complicated and fragile logic, as Nikita pointed out, you
> could put all of your functions inside of a "functions,php" in a
It's the same as making it Functions.php and a class. I don't see why we
should overhaul the autoloading in the engine and add so many complexity
just to av
Hi!
> function short (...$args) {
> if (count($args))
> return long(...$args, "some value");
> }
This is exactly the problem. Since $args has undefined number of
arguments, there's no way to determine where "some value" ends up. Which
means it's impossible to understand what's going o
Hi!
> Not sure I get what you mean. All languages with argument unpacking
> allow this. It's not commonly needed, but there are uses for it and I
I mean this:
>>> a = [0,3]
>>> range(*a)
[0, 1, 2]
>>> a = [1]; b = [2]
>>> range(*a, *b)
File "", line 1
range(*a, *b)
^
SyntaxE
Hi!
> We got a performance win from exactly this at Facebook. We have some
> extensions in HHVM to autoload that allowed us to remove almost all
> our *_once calls.
But autoloading does not remove require - you still have to load the
files. Only thing that can be removed is a non-loading require
Hi!
> This RFC proposes to add a syntax for argument unpacking:
>
> https://wiki.php.net/rfc/argument_unpacking
>
> Basically, this is the "complement" of the variadics RFC: It is not about
> declaring variadic functions, but about calling them.
This is just another way of doing call_user_f
Hi!
> A good example would be function forwarding for variadic functions,
> without resorting to call_user_func_array.
What's wrong with "resorting to" call_user_func_array?
call_user_func_array is a PHP function and not some dark magic that one
should avoid using unless it is absolutely must.
-
Hi!
> This seems to be the core of your argumentation in this thread: "Why
> don't you just use Foo::bar() instead of foo\bar()?"
>
> In which case, I wonder why we have functions at all. We could just use
> static methods instead after all. Maybe we should deprecate function
> support?
Maybe we
Hi!
> Assuming you mean call_user_func_array, yes. This is just syntax sugar
> for call_user_func_array. Advantages of this syntax over cufa are
> outlined here:
> https://wiki.php.net/rfc/argument_unpacking#advantages_over_call_user_func_array
The only case that I see that could make sense is $d
Hi!
> A function is stateless [1], a method isn't. A function operates only on
> the passed parameters [1], the method operates on the parameters and the
> context it inherits from the instance (non-static), or class (static and
> non-static).
Static method is stateless in the same meaning as una
Hi!
> So nothing changes from present (at all) unless a function is not
> defined. Today, that's an error case. So the only performance change
> occurs if zend_hash_find (which is already there) returns FAILURE. THEN
> the logic which includes autoloading would run.
I see a number of places where
Hi!
> Just to say : one benefit of this work would be to finally have autoload
> functionnality (which is a Core feature IMO) included in Zend/ and no more
> in an extension.
PHP core already has autoload functionality. And I don't see how with
function autoloading (which has no natural mapping a
Hi!
> Well, static methods aren't the same as functions.
The big difference being?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
> And to continue the discussion, I recall that we, as PHP contributors,
> disagreed to include a PSR-0 compatible autoloader into Core.
This has nothing to do with PSR-0 in core. This has everything to do
with the fact that class-per-file is an accepted pattern in PHP and many
other language
Hi!
> I disagree on the basis that namespaced functions/constants *do* fit the
> same autoloading paradigm.
If they're already namespaced, what prevents one to put it in a class
and use good old PSR-compatible loading?
> Those function calls would only kick in if the function/constant wasn't
> a
Hi!
> It is
Oops, clicked too soon. I wanted to conclude that I think it is too many
complications in the engine for too little gain.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To u
Hi!
> I have created a new draft RFC implementing function and constant
> autoloading in master:
>
> https://wiki.php.net/rfc/function_autoloading
>
> All feedback is welcome.
I think it is an unnecessary complication. Classes fit autoloader
paradigm nicely, since the usual pattern is one class
Hi!
> I respectfully disagree.
>
> The first method requires at least one parameter (or two, depending on
> the pending clarification in the other thread) , and the latest: zero
> or more (or 1 or more).
Yes, this is true. But how it is an objection? LSP allows to weaken
preconditions, but not t
Hi!
> Unfortunatelly nobody pointed out that it has to be discussed in the mailing
> list in the mentioned bug report. We have stated that we have a problem
> with JSON license and we had to solve the problem we had.
> I consider the licensing issue as a bug and it's always better to track it
> as
Hi!
> Subject: Switch from json extension which have a problematic (non-free)
> license to jsonc dropin free alternative.
>
> RFC: https://wiki.php.net/rfc/free-json-parser
>From what I see in the benchmarks, while encoding is on par with current
implementation, decoding is more than 2x slower.
Hi!
> functions should be able to ignore some arguments, especially ones that
> are optional anyway.
>
>
> This is not the current behavior, so why should we change it? See:
Because it makes no sense?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)45
Hi!
I like the idea, the concept of capturing "rest of args" is pretty
common. But couldn't we in addition have func_get_args() be able to
receive an int argument that would produce "the rest" in an easier way
for those that prefer func_ger_args()?
I wonder if this makes harder to implement named
Hi!
> * Set date.timezone = UTC as the default INI value
> * In php.ini-production and php.ini-development uncomment the
>;date.timezone =
>line, i.e. change it to
>date.timezone =
I think this is fine but for the distros that ship with empty php.ini
it'd still produce a war
Hi!
> And while the issue was first reported by Debian, the other
> distributions share the same concerns. This is why PHP should consider
> this - because the other parts of the eco-system are already going
> forward with this.
What we need to consider this extension as a replacement for core JS
Hi!
> http://marc.info/?l=php-internals&m=136768085009866&w=2
This is great but this is not exactly what I'm talking about. There's a
big difference between having an extension that does JSON in PECL and
replacing part of PHP core (and very commonly used part) by something
else. It very well may
Hi!
> I would like to react on Stat's "it's-not-our-problem" comment in
> https://bugs.php.net/bug.php?id=63520
I assume by "Stat" you mean myself, though I'm not the only one who
expressed the same sentiment of questioning why this is submitted as a
"bug" in PHP. Assuming that, below are my thou
Hi!
I'm looking into tests fails that I get with mysqlnd and mysql enabled,
and on bug_39858.phpt I've noticed a strange thing. The code goes like this:
$stmt = $db->prepare("CALL p()");
$stmt->execute();
do {
var_dump($stmt->fetchAll(PDO::FETCH_ASSOC));
201 - 300 of 1808 matches
Mail list logo