On 14/07/2020 00:46, Dale Hirt via internals wrote:
While we will no longer work on PHP builds for Windows, expect to see us remain
involved in PHP in many ways across MS as we continue supporting PHP developers
and collaborating with the community on security fixes.
I admit to a certain degr
On 13/07/2020 19:32, Gabriel Caruso wrote:
This warning does not make much sense as the magic method is executed
regardless of its visibility. Should it be dropped?
This seems to be the bigger issue... if something is specified as
private, nothing outside its scope has any rights to access it, a
On 10/07/2020 09:54, Nikita Popov wrote:
For me, dealing with PHP <-> PECL moves is an important part of adopting
namespaces in php-src, and I don't think the current proposal addresses
this issue sufficiently. (One way to address it would be to drop the PHP\
prefix, and use unvendored namespace
their respective namespaces keeping the whole thing much more self
contained and tidy.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
override functions
while keeping the same base syntax.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
too messy.
I'm not sure what the alternative should be though. It seems like the
accessor syntax would be the only long-term clean way.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
t a
class might be omitted (such as if an optional package is not installed).
At which point we're left with @@@ and that's getting into silly-land.
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 16/06/2020 13:14, Michał Brzuchalski wrote:
I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.
IMHO this RFC should not come to a vote, the current RFC process is
ill-equipped to
On 22/05/2020 19:32, Rowan Tommins wrote:
* They might even prefer your RFC, which is still marked "Under
Discussion": https://wiki.php.net/rfc/php_namespace_policy
Even though the two RFCs were seperate and created without each others
knowledge, I don't know how people would feel about holdin
ad an opportunity to make their case for their individual
usage of \PHP.
Should this vote fail, \PHP effectively changes from a reserved
namespace, to a dead namespace.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 15/05/2020 23:03, Arnold Daniels wrote:
Hi all,
I'd like to restart the discussion for the strict_opterators RFC (
https://wiki.php.net/rfc/strict_operators).
I think this kind of change will have a long term positive impact, but
it will require a lot of work to update code.
IMHO we need
On 15/04/2020 12:21, Mark Randall wrote:
https://wiki.php.net/rfc/php_namespace_policy
As it has come up a few times, I wanted to provide examples of where
programming languages mount their own standard libraries inside a main
namespace:
Java (java.*)
https://en.wikipedia.org/wiki
ere gone.
I concur with Marco's statements.
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
two majors minimum, possibly
more.
Thank you for the contribution.
However, such a change would never, ever be accepted. With good reason.
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 15/04/2020 12:21, Mark Randall wrote:
https://wiki.php.net/rfc/php_namespace_policy
Just an update in light of the two different RFCs.
Having chatted with the other RFC authors in R11, rather than racing to
see who can get their RFC to vote first, it seems like there's room for
On 15/04/2020 14:20, Remi Collet wrote:
Le 15/04/2020 à 13:21, Mark Randall a écrit :
Extension (pecl or other) can be include in core later
or core extension dropped and move to pecl.
Quoting the RFC:
Once approved, a namespace that is a child of \PHP will remain
exclusively for the
e and the RFC which approved it.
In that respect it would be no different than arguing over any other
name which can already happen.
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
lled token, or attribute, at
which point we are back to square one, a problem which can be almost all
together avoided by adding a "feature" specific namespace under \PHP.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
internals
that the use of \PHP was permitted and encouraged.
https://wiki.php.net/rfc/php_namespace_policy
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
s with long lists of parameters so that
they need to be on their own lines?"
The answer to that is a pretty resounding "no".
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
If annotations RFC gets passed, there will likely be a suggested
annotation for marking things as intentional, but I would assume it
would carry no runtime effect.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
s
to become a first-class feature, error handling should reflect as such
and any attempt to use objects without the appropriate handlers being
installed really should result in an error being thrown just as it would
be if an undefined method was called.
Mark Randall
--
PHP Internals - PHP Ru
fairly easy I'd think. We already have the
APIs and it's not much different from how the testing pipeline is set up
for github.
The docker-official PHP repos have some nice extra tools to go with them
for installing extensions mind.
Mark Randall
--
PHP Internals - PHP Runtime Developme
tainty and possible unexpected interactions.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ng multi-request processes, as at that time there would be a
clear need for a self-contained request-specific request / response object.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
s which weren't the actual cause of failure, or worse, feeling
fed up and losing interest in future contributions because they've
failed and have no idea why.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 19/03/2020 14:25, Kalle Sommer Nielsen wrote:
Why are we only attempting to harvest the negative thoughts (with the
word negative chosen carefully here as voting "No" is seemingly an
offense to some), why do we not also record why a feature was voted
in?
Well a significant part of the purp
ve feedback for the RFC
author and the wider community.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 18/03/2020 23:22, Kalle Sommer Nielsen wrote:
I am not gonna personally answer a survey everytime I vote against a
feature. This is why we have a discussion period to raise issues, of
course not everyone will raise all their concerns to each and every
RFC (me included, take the annotation RFCS
On 01/03/2020 13:29, Mark Randall wrote
I have opened voting on the get_debug_type RFC:
https://wiki.php.net/rfc/get_debug_type
Voting will run for 2 weeks and will close 2020-03-16.
Voting has now closed.
The RFC has passed with 41 in favour and 3 against.
--
Mark Randall
marand...@php.net
/php-src/pull/5265
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
just feels so wrong, but the only thing that feels worse is that we
probably couldn't pass removing null++, at least in the base version,
and that may set up null-- as the least-worst option.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 02/03/2020 14:08, Rowan Tommins wrote:
The problem with this kind of behaviour change is that there's no way
for PHP to know whether a particular piece of code has been changed to
expect the new behaviour or not
Lump it in with editions maybe?
--
PHP Internals - PHP Runtime Development Mai
Greetings,
I have opened voting on the get_debug_type RFC:
https://wiki.php.net/rfc/get_debug_type
Voting will run for 2 weeks and will close 2020-03-16.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
On 15/02/2020 14:32, Mark Randall wrote:
Greetings,
https://wiki.php.net/rfc/get_debug_type
Just a heads up that I will be putting this to the vote tomorrow.
As this seems fairly uncontroversial, and in the absence of any
well-supported suggestions, the vote will be on adding this as
de /
migration tool would be rather well-received, an easy mechanism to scan
a file / directory for standard extension functions with known reference
args and re-write them appropriately.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 17/02/2020 08:42, Nikita Popov wrote:
Can you please add some examples for the behavior? Preferably the precise
output for all primitive types, for classes and for anonymous classes.
Added to RFC
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.n
eaning
towards a general "No".
What I can't express on this strawpoll though, is that I would
unequivocally vote against "any function or method call" in all
circumstances.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
T
On 16/02/2020 10:16, Mike Schinkel wrote:
Why "debug" type?
I would imagine because it is only really useful in the context of
debugging. There is no reason to ever expose such information to userland.
The name is up for debate.
--
Mark Randall
marand...@php.net
--
PHP Inter
verloading operators on
objects that don't have the relevant method available should trigger an
Error.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ade that a supermajority may exist in
a straight up or down vote rather than a 3-way
(https://wiki.php.net/rfc/engine_warnings).
So on one hand, consistency is good.
On the other hand, being consistently bad is still being bad.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Developme
, thus get_debug_type will return
"int" rather than "integer" etc.
https://wiki.php.net/rfc/get_debug_type
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, and there is an exactly zero percent
chance of it being removed at any point in the next 50 years.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
or cannot exist
in a reasonably performant way? Doesn't seem so except for a readonly
property.
If not, leave it to userland.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
on
would be to simply remove support for them entirely in favour of static
methods, and at that point the door is open to make functions and
constants be global-only.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I'd much rather have something like:
declare(ambiguous_element_lookup=0)
declare(ambiguous_element_lookup=off)
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t was a warning now, it
would end up a compile error a few years from now.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hen PHP8 lands.
+1 from me.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
of
function / constant / anything-but-class level autoloading, things might
as well be in a readily available location.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 31/10/2019 17:01, Mark Randall wrote:
https://wiki.php.net/rfc/deprecate-backtick-operator-v2 is now open for voting.
This vote has closed with 11 in favour and 26 against.
Backticks will therefore be left unaltered.
Thank you to everyone that voted.
Mark Randall
marand...@php.net
.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
https://wiki.php.net/rfc/deprecate-backtick-operator-v2 is now open for voting.
This is a standard yes / no vote, requiring a 2/3 majority to pass.
The vote will run for 2 weeks and will close on 2019-11-15.
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
the PHP Internals News podcast.
Mark Randall
marand...@php.net
been accidentally sitting in an outbox for
a bit too long and has just sent, but the vote has been underway for a
while now.
It currently has more than 90% in favour with good turnout.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.ph
On 27/10/2019 02:12, Mike Schinkel wrote:
Hello all:
And for everyone:>
What do you think of this as a potential future for PHP?
I had received the impression that a lot of the problems for performance
optimizations relate to how PHP can shift things around at runtime,
where identical code a
think easy cognition has likely gone out the window.
There are plenty of much more expressive ways of doing this without
introducing new syntax IMHO.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
is to
be found.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
l fopen('missing.txt', 'r'),
FileException => null;
if ($x === null) {
die('File could not be opened.');
}
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e to add a
token that would effectively no-op in all circumstances.
It sounds like a job for a static analysis comment:
/** @DisableSwitchStatementFallthroughWarning */
switch ($x) {
case 1:
$x = doSomething();
case 2:
doLaLaLaLa();
break;
default:
doTralala();
}
--
Ma
On 16/10/2019 02:46, David Rodrigues wrote:
Hello. I like to suggests a discussion about a FR to make possible to
inline switch, as an alternative to nested inline conditionals.
```
http://www.php.net/unsub.php
On 11/10/2019 11:25, Nikita Popov wrote:
Purely syntactical deprecations, such as the recently discussed case of
backticks, but also the already accepted deprecations of the "alternative
array access syntax" and the (real) cast, can be performed automatically
and with perfect reliability.
I ima
owableForSureThisTime $ex) {
}
^^ Compiler Error.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 10/10/2019 23:04, Walter Parker wrote:
If this truly is the problem that you say it is, there should be plenty of
documentation online as to the issues that it has cause. Maybe you could
post some of the better cases (as the the responsibility of the person
suggesting the change to provide evi
nd poorly understood syntax, and people should
at some point in the next 4 or 5 migrate to the much more obvious
shell_exec.
By writing the RFC, it's pretty obvious which one I think is the best
and most realistic course of action.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
leaves us with the choice that's within our power, deprecation and
eventual removal of backticks in favour of something that's much more
obvious in its intent and much less easy to miss.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
tual topic of
the RFC, rather than trying to shift the conversation towards who can
and cannot propose RFCs :-)
If you want to discuss changing the RFC mechanics and who is entitled to
make them, please make your own RFC.
Thank you.
Mark Randall
--
PHP Internals - PHP Runtime Development Maili
applies to most things, not just PHP.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RFC states, there are already widely used tools available which
can do this reliably:
https://github.com/FriendsOfPHP/PHP-CS-Fixer
backtick_to_shell_exec
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
just having
identical behaviour, the compiler actually transforms the AST into a
userland function call to the named shell_exec function as per
zend_compile_shell_exec.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ght of the existence of
better described and more well-known functions exhibiting identical
behaviour.
This RFC only covers the issuing a deprecation notice, and its complete
removal would be contained within a separate RFC.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To u
itor
Avoid the XML parsing code. It's pure cancer.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
haviour in light
of the existing internals guidelines regarding considerate posting, and
they may find themselves prevented from continuing those actions.
Something I think most people would consider entirely reasonable.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To u
BC break due to requiring bitwise mask comparison in existing
handlers.
Either way, this this would allow easily differentiating engine warnings
that will become more prominent in this RFC, with those contained in
PHP_FUNCTION scope.
--
Mark Randall
--
PHP Internals - PHP Runtime Development
e can probably find a way around it, at least
when running containerised.
Are you referring to installing shared libraries on the host?
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
u want a per-file opt out, the notion of
declare(sloppy=1);
Has already been jokingly proposed, and I would personally have no
problem with it if people want to opt-in to less reliable enforcement...
but once again, I stress that the defaults should always be best-practices.
--
Mark Randal
Registration recommended by participants of 11
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 05/09/2019 22:45, Benjamin Morel wrote:
. One
thing that could be checked, is whether their API allows retrieving the
whole discussion history programmatically. If so, one could setup a
database to sync all messages to on a regular basis, so that the PHP
project could move the discussions back
every single sub-branch individually to get the
final word.
Something I am finding hard on Github, and maybe it's just because I
haven't found the option yet, is finding new posts.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: htt
g at the code.
To use the analogy someone posted elsewhere... the training wheels are
coming off. Time to be responsible and type those few extra characters
to be clear on your intent.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
features that could help us to build
new features".
The manager says: "Lay this out to me"
You reply:
"It's like our company car still works, but it no longer tighter meets
emissions standards so they won't let us take it into the city any more"
"Crap"
comes.
Don't build your business on a foundation of eggshells and then complain
when something comes along that makes those eggshells crumble.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
w would it?
Besides, we have tools available for years now to make this behaviour
more defined:
$counts[$key] = ($counts[$key] ?? 0) + 1;
"If $counts[$key] is not set, use the value 0".
Null Coalescing was explicitly designed to provide for this behaviour.
--
Mark Randall
--
PHP Int
not as focused on the
quality of their code as we (and their customers) would perhaps like
them to be.
For everyone else, it's one more tool to help make us aware of problems,
and prevent those problems from propagating along the stack and
effecting other things.
Bring it on.
--
h_dump(
fn() => func_to_test("hello"),
fn() => func_to_test(1234),
fn() => func_to_test(false)
);
I am however, unsure where this script should be placed in the codebase.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
knowing that "PHP" has agreed to weigh certain general concepts in a
particular way.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
rm game plan for PHP, and build a consensus
on things such as strict typing, overloading in the core functions, and
perhaps most divisively, if "cleaning up the language" is in itself a
viable justification for backwards compatibility breaks, and if so, what
weight it should carr
l the autoloader internally but it would require userland
loaders to be upgraded with it, not exactly a huge stretch, especially
with most things being composer-based, but a dummy class would make it
work out the box, including optimization steps like dumping the class list.
Mark Randall
--
my own packages which
deal with wrapping up css / js / html template files.
Perfect for runtime, not so good for compile time, but if I'm wrong I
dare say someone will let me know.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
not use an autoloader, the
__nsmeta.php would need to be loaded first, this is something that
PHP7.4 autoloaders would need to take into consideration.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
o
package and may depend on that package definition to control its
behaviour (especially if it gets loaded up with declares or editions).
I'll simply be replacing my ubiquitous strict-types declare with
whatever was used to reference this package.
Mark Randall
--
PHP Internals - PHP
asic comments?
One thing I did see in the GD library with _php_image_create_from is
that ZPP is different depending on logical expressions, rather than
pre-processor statements. How should these be handled?
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsu
st of backwards compatibility. Prioritizing backwards
compatibility did not receive a strong response.
I seem to remember listening to Nikita on Derick's podcast a while ago
where he made comment on his observation that newer generation
programmers were looking for improved typing and strictne
On 10/08/2019 11:56, Nikita Popov wrote:
Hi,
Lack of type information for internal functions in Reflection is a
long-standing issue. In PHP 8 we finally have all the necessary technical
groundwork done to support argument and return type annotations on internal
functions at scale.
Question - I
patibility on the existing core functions.
The entire argument order issue could potentially be wrote off with SON.
My guess is that whatever happens, it's going to require one version
that really brings the pain, to set the groundwork for the future.
Mark Randall
--
PHP Internals - PHP
just moving the version definition to a tag
instead of a declare, and having a "Anything and everything new" version.
Is there a major difference I'm not immediately seeing?
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 09/08/2019 08:15, Zeev Suraski wrote:
You seem to believe that C++ is inherently superior to C. And it's
entirely within your right.
However, there are projects - to this date - that prefer C to C++ for a
variety of reasons. PHP is one of them, and others include the Linux
kernel, redis, ngi
ntion.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ability to rip out
everything which wasn't kept would no doubt simplify a lot of things,
but I agree with Nikita's point that it only kicks things down the line
until the next break.
I think side-by-side engine versions are likely going to be the end
result if it's poss
s obviously a big challenge for the internals team and
its contributors to create coexistent systems with versioning, but I
would simply offer the following:
If you're not going forward, you're falling behind, and sometimes going
forward requires sacrifice.
Mark Randall
--
PHP Int
iously
omitted), would treat code which was previously explicitly specified as
valid, as no longer valid, and would expose it to the world.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
101 - 200 of 237 matches
Mail list logo
