Hi!
I am having a really hard time figuring out why this is throwing a segment
fault.
char *input_file = NULL;
char *output_file = NULL;
zend_bool formatoutput = 0;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, ss|b, input_file,
output_file, formatoutput) == FAILURE) {
s requires
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
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
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!
* 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
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!
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
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 the
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 make
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 relying
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 will
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
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
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 mentioned
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 sense
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 too
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!
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:
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 objects,
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?
--
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!
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!
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 as
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:
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
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 use
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
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!
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
Hi!
Commit:7c2489751cc48961487edd69b49083d4ca6b4828
Author:Sara Golemon poll...@php.net Mon, 7 Jul 2014 12:19:11
-0700
Parents: 888fb3323ed1bb728064f27a6127d194eb92f9ee
Branches: master
Link:
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 offensive
Hi!
A package licensed under the PHP License must be released under
php.net (f.e. gtk and smarty are not listed under
Why? I don't see any reason why software licensed under PHP License must
be released under php.net. Could you explain?
However using the PHP License for a random extension on
Hi!
I think the difference is that we have a couple of clauses which sounds
weird/makes no sense when the license is used for extensions or anything
else than php-src, like clause 3, 4 and 6.
And this is what they were complaining about in the thread referenced
from their reject faq:
Hi!
Who would benefit from filing a lawsuit on the basis of that part of the
license? If not enforcing it anyway, is it useful? Removing a rule would
certainly make it easier to understand.
Nobody's filing any lawsuits so far. We're just asking if you're
developing some software based on PHP,
Hi!
I think the difference is that we have a couple of clauses which sounds
weird/makes no sense when the license is used for extensions or anything
else than php-src, like clause 3, 4 and 6.
And this is what they were complaining about in the thread referenced
from their reject faq:
Hi!
Debian began to send requests to change PHP license for the PHP
Extension arguing that the PHP License is only valid for PHP itself.
That's like saying Apache license is only valid for Apache httpd, and
Mozilla license is only valid for Mozilla Firefox. Makes little sense to
me. OTOH, I
Hi Joe!
I think however anyone sees the announcement you have authored, it is a
new thing that was never done before on php.net, and we all agree on
that. And it came as surprise to many participants of the project. I
think in the PHP project we see php.net as something representing all of
us,
Hi!
We have 5.4.28 RC1 on:
http://downloads.php.net/stas/
Please test it and report any bugs or regressions that you may notice
through the bug system at bugs.php.net.
If no serious issues are found, the final release are planned in 2 weeks.
Regards,
Stas Malyshev
PHP 5.4 RM
--
PHP Quality
Hi!
We have 5.4.26 RC1 available on
http://downloads.php.net/stas/
Please test it and report any bugs or regressions that you may notice
through the bug system at bugs.php.net.
If no serious issues are found, final releases are planned in 2 weeks.
Regards,
Stas Malyshev
PHP 5.4 RM
--
PHP
Hi!
I use add_assoc_string() when the argument is string,and it works
fine,but when the argument is a array,and i use
add_assoc_zval(),the result is not what i want.
It would be useful to describe here what not what I want looks like.
here is my code:
if(Z_TYPE_P(value) ==
Hi!
I’d rather see discussion on the subject than an immediate revert; not that
I’m against reverting in any way. Let’s make the changes, if we do decide
to make any, be beneficial.
I don't think this is how it should work. This is a pretty big change in
voting process, it should be discussed
Hi!
We have 5.4.24 RC1 and 5.5.8 RC1 available on
http://downloads.php.net/stas/
Please test it and report any bugs or regressions that you may notice
through the bug system at bugs.php.net.
If no serious issues are found, final releases are planned in 2 weeks.
Regards,
Stas Malyshev
PHP 5.4
Hi!
On Sun, Nov 17, 2013 at 3:52 PM, Stanislav Malyshev s...@php.net wrote:
Commit:989246fb3b836e1695d3d869bac4ad11756bd774
Author:Stanislav Malyshev smalys...@gmail.com Sun, 17 Nov 2013
15:52:01 -0800
Parents: 17380e9c9de75d0b6037b8d3dbab6b347baadef1
Branches: master
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
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
Hello!
The PHP development team announces the immediate availability of PHP
5.4.20. About 30 bugs were fixed. All users of PHP 5.4 are encouraged to
upgrade to this release.
For source downloads of PHP 5.4.20 please visit our
downloads page: http://www.php.net/downloads.php
Windows binaries can
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
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 explicit
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 back to
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!
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!
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
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:
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
right
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.
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. 227
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 to
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!
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 this
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
place
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
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
proposing
Hi!
Log:
Implement phase 1 of rfc/incompat_ctx
Just changing the error level of the message from E_STRICT to
E_DEPRECATED. This comes one version later than the timeline
mentioned in the RFC.
Please add it to UPGRADING and NEWS.
--
Stanislav Malyshev, Software Architect
SugarCRM:
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!
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
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
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!
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 at
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!
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
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
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 should
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 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_func,
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!
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 stdin, line 1
range(*a, *b)
^
SyntaxError:
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 avoid
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 on here.
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!
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!
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 to
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 per
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
Hi!
Not only users, but other extensions rely on it as well. couchdb and
couchbase are examples. And solr links directlly to ext/json:
#include ext/json/php_json.h
See http://svn.php.net/viewvc/pecl/solr/trunk/php_solr.h?view=markup
This is another thing to consider. For a drop-in, at
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 thoughts on
Hi!
http://marc.info/?l=php-internalsm=136768085009866w=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 be
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 JSON
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
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!
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/
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));
Hello!
The PHP development team announces the immediate availability of PHP
5.4.19 and PHP 5.5.3. These releases fix a bug in the patch for
CVE-2013-4248 in OpenSSL module and compile failure with ZTS enabled in
PHP 5.4, which were introduced in previously released 5.4.18 and 5.5.2.
All PHP
Hi!
use bar as bar;
Hmm... they probably should both produce a notice. But if it's hard to
do, then ok to do the same thing as class does.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development
Hi!
May I cherry pick the commit? Or
could you merge it to 5.5.3 branch?
5.5.3 is for fixing one specific problem - UMR in openssl fix. So I
don't think we should add more code to it, I think it'd be fine to get
this in a scheduled 5.5.4 release.
--
Stanislav Malyshev, Software Architect
Hi!
I didn't merge the change to 5.5.3 branch. It might be better
cherry pick change to 5.5.3 branch.
It doesn't look like something critical, so I don't think there's a need
to put it into 5.5.3. It will be picked as a part of scheduled release.
--
Stanislav Malyshev, Software Architect
Hi!
This is because I didn't edit these files.
Stas, are you going to add explanations and doc? Or shall I?
If you could fix it it'd be great.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development
Hi!
Listening on http://localhost:8964
Document root is /home/smalyshev/php-src/sapi/cli/tests
Press Ctrl-C to quit.
Quite strange... Why is the server's output shown here?
I don't know, but this is what happens with this test, so it needs to be
fixed.
Notice: fwrite(): send of 8192
Hi!
RFC: https://wiki.php.net/rfc/use_function
Patch: https://github.com/php/php-src/pull/388
Looking at the patch:
1. use function bar as bar;
does not produce any warning
2.
use function x\foo as bar;
function bar() {
echo OK!;
}
Does not produce any warnings or errors, though it
Hi!
Though obv, in reality we wouldn't use runkit_constant_add(), it'd be a
new opcode which had the same effect. This is basically transparent to
opcode caches, allows the constant to actually change based on runtime
If the class definition can actually change at runtime, I think it'd
make
701 - 800 of 2366 matches
Mail list logo
