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 many
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!
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
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
and
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!
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
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
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 other
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:
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
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, I
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
Hi!
?php
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 and dereferenced
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!
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, I
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
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
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
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!
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 next
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
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!
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
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!
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!
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));
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!
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
201 - 300 of 1748 matches
Mail list logo