e we didn't even manage to remove "var" in favour of
"public", but I wanted to say it for completeness.
Maybe someone can come up with some other variation or compromise?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ent an initial draft to start the discussion, because the current
behaviour is quite hard to explain in a short e-mail.
Please let me know your thoughts.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
e what's really needed is to draft a new copy of the policy document,
updating or removing those parts that are no longer relevant, and adding a
timeline for the pre-release phases?
Or possibly there's a different document I should be looking at, and the RFC
could contain proposed edits to that?
eclare() covers.
Wherever it is used, "null" is a confusing and often controversial
concept. In different contexts, it is used for different things, and has
different ideal behaviours. It's a whole debate on its own, and bringing
in other types of coercion just confuses the conversation.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
if the [imaginary] sql_escape function doesn't reject
nulls, you may not notice the bug until you've ended up with garbage in
your DB.
Regards,
--
Rowan Tommins
[IMSoP]
advance as part of preloading, but that
seems to be mostly orthogonal to what we're talking about here in terms of
static analysis.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
!
maybe stabilising them for deployment, maybe just using the existing OpCache
preloading.
If you use the JIT in advance, it becomes a very different tool - the point of
JIT compilation is to make use of runtime information about hot paths, the
actual types of dynamic arguments, etc
Regards,
--
Rowan Tommins
[IMSoP]
optional. We could produce an error if any generic/extended type was
encountered without being preloaded, but that poses a dilemma for libraries:
either don't use the new types, or impose a requirement for applications to use
preloading. I'm not convinced there's an easy compromise here.
Regards
chance to break compatibility is
in 9.0, not 8.anything. While there are often grey areas around this
rule, there is absolutely no question that empty() could be removed any
time before that. If anything, proposing removal in 10.0 might be more
reasonable.
Regards,
--
Rowan Tommins
[IMSoP]
--
FromTimestamp($value / 1_000_000) - as
discussed above, this will not lose any accuracy for dates in the next
200 years or so.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
a one-second
accuracy for any time 285 million years into the past or future.
https://www.wolframalpha.com/input?i=2**53+as+unix+timestamp
Possibly you're thinking of a representation that counts integers as
milliseconds or microseconds, instead of seconds?
Regards,
--
Rowan Tommins
[IMSoP]
Coming back to the lack of a build stage, that also means type aliases would be
opaque to compile-time optimisations, which are mostly per-file. I'm not sure
what impact that would currently have, but it's worth thinking about.
Regards,
--
Rowan Tommins
[IMSoP]
t;type declarations can no longer be trusted".
Regards,
--
Rowan Tommins
[IMSoP]
t
}
The actual attributes could either be built-in, making them official
parts of the language, or managed in a library that static analysers
co-operate on, making them standardised but more agile.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To
have a productive discussion about a
feature, try to come across more positively, e.g. "I was thinking it would be
useful if the language had this feature, and was wondering if it's been
discussed before?" Bonus points for adding "... and if there's a way I can help
add i
rns about how to fit
them with the existing language. I will continue to engage in good faith in
discussing those proposals, but find it disheartening to be labelled as part of
a "camp" that needs to be "overcome".
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime
tputOptions() method to be called
before asXml(). Still a bit clunky though.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
off-topic one: someone really
needs to look into adding opt-in block scoping to PHP, similar to JS "let". It
would fit so well with proposals like this one!
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ilter($array, $callback, $mode) );
}
// In another file:
var_dump( backwards_array_filter($some_array, call_me_back(...)) );
Regards,
--
Rowan Tommins
[IMSoP]
erty that DOM would expose on each node.
For debug output, the main concern is showing what you'll get with
various styles of access in SimpleXML, so a single "@text" =>
"foobarbaz" would make sense; or maybe even "(string)" => "foobarbaz"
and rename &quo
your other work.
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
tation.
[1]
https://github.com/php/doc-en/commit/56562880bd287b2d96519932044f911db518f2cf
[2] https://wiki.php.net/rfc/precise_session_management
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
on we want to go, but thought I'd
throw it out there.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
the
(very small) benefits of removing the extra signature until the final
removal anyway.
Regards,
--
Rowan Tommins
[IMSoP]
something specific to interface default
methods. The lack of those constraints in PHP is likewise not something
that's specific to this proposal, the language *always* allows you to
attempt any method call on any object, including $this, even if a type
checker would say the call is invalid.
Regards,
--
Rowan Tommins
[IMSoP]
"request_form_populate_globals"?
Regards,
--
Rowan Tommins
[IMSoP]
h be chosen with new users in mind, not
fudged based on a combination of current and new naming styles.
Once the deprecation period is over, we should be left with a pair of names
that obviously signals the difference; or, we should be left with only one
function.
Regards,
--
Rowan Tommins
[IMSoP]
ve a clear choice between
the two. Deprecate the existing function completely.
All the other suggestions seem likely to create a lot of confusion, and
not actually leave us much better off in the long term.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Ma
is is also hinted at in the exchange between Levi and Alexandru about
private methods on the interface itself, which would not be visible
anywhere outside the interface. Again, that's different from traits,
where members marked "private" are private to the target class, not the
trait.
ass A doesn't define a contract for method
bar falls to static analysers, and the same would be true for default
implementations on interfaces.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
signatures, so what does making it the preferred signature (with
users of the other having to change their code) have to do with
"history/legacy"?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
] );
} );
... or macro-based:
$name = null;
$cache->memoize!($name, block {
let $result = $db->query('some SQL');
$name = $result['item_name'];
} );
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
eedback or suggestions on the documentation when I
get a chance.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
working fine for 20 years.
Regards,
--
Rowan Tommins
[IMSoP]
on that question, but I
thought I'd raise the concerns early to avoid surprise.
Regards,
--
Rowan Tommins
[IMSoP]
it, the more I'm leaning towards not doing
anything being the best choice. The benefit seems small, and the cost high.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
g an object instance". Thus, the first is
"session_set_handler_functions" or "session_set_handler_callbacks" or so,
and the second is "session_set_handler_object" or
"session_set_handler_instance" or so.
Without any suffix at all, it seems like "set a session handler the normal
way" vs "set a session a special different way"; like how
"array_merge_recursive" is a special version of "array_merge".
Regards,
--
Rowan Tommins
[IMSoP]
meter form,
I'm not sure. As you say, it's probably pretty rare, particularly because
according to the docs that parameter is ignored for most file formats the
function supports anyway.
Regards,
--
Rowan Tommins
[IMSoP]
posing - how does an alias fit in to something that's about
splitting a function into two?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
t think I'd be able to answer.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ssible language, and I care less about minimizing
> backward compatibility breaks.
I think Claude is taking the same premise, and reaching a different
conclusion: returning true is consistent with the other methods on the class,
and that consistency makes it more predictable and more accessible.
Regards,
--
Rowan Tommins
[IMSoP]
general concept of this RFC, as it is placing a
burden on users for the mostly minor convenience of maintainers; but I think
you've done a good job responding to concerns and improving the proposal.
Regards,
Hi Máté,
Sorry I didn't get round to replying to this sooner, particularly this point:
the beginning of a larger project to standardise and encourage such
attributes.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
from a base class, at which point there is a contract that all
descendants of that base class will have the property available. So it seems
logical that that contract could also be included in an interface.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development
them.
So the argument is that the key estimate for whether to include it in the
engine is how many users will add the attribute, but not run a static analysis
tool. If that number is very low, adding it to the engine has a very low value.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals
can and do perform static analysis.
Regards,
--
Rowan Tommins
[IMSoP]
e everyone having to rediscover them the hard way.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
defines "graphemes" or
"grapheme clusters" to better match the common intuition of what a "character"
means.
Perhaps we should instead, or also, add a "grapheme_strpad" function to
ext/intl?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
or rework
and forking far more restricted.
Regards,
--
Rowan Tommins
[IMSoP]
ributors who could work on it - as long as they didn't hit a
limitation that needed to be fixed in the C layer.
Regards,
--
Rowan Tommins
[IMSoP]
n PHP then bundled
are things that are so low-level that it's hard to get them wrong; the
building blocks that the community will use to build things like Monolog
and Guzzle.
Regards,
--
Rowan Tommins
[IMSoP]
already out there.
Bottom line, I think there is some merit in having part of the standard
library be written in PHP rather than C, but we'd still want to be very
conservative in what went in there, because most of the downsides of
locking it to the PHP release cycle would still be there, and Composer
se
omise might be to have a planned cycle, but with some leeway for
major projects, e.g. "a major release will happen no more often than every
4 years, and no less often than every 6"; or, to put it a different way,
"there will always be an x.3 release, and never an x.6".
Regards,
--
Rowan Tommins
[IMSoP]
hanged a whole list of resources to objects in PHP 8.1, it's
clearly not considered that massive a shift to most people
https://www.php.net/manual/en/migration81.incompatible.php#migration81.incompatible.resource2object
Regards,
--
Rowan Tommins
[IMSoP]
the most promising responses when banging
that drum in the past.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
d. If you've got an up to date PhpStorm,
you can actually use it directly from a scratch file. (Huge shout-out to Sjön
Hortensius for making and maintaining such a useful tool!)
Regards,
--
Rowan Tommins
[IMSoP]
have a rush of changes because "we've only just decided 9.0 is
soon".
It also helps avoid putting a release number on an experimental feature that
might never arrive, as with Unicode strings in 6.0; or that might turn out to
be less important to most users than other changes, like the
ror: Uncaught Error: Undefined constant "NoExist\TEST" in /in/gltKN:5
Take the constant part away so that the next line runs, and
https://3v4l.org/q0XQO shows the fully qualified name right back up PHP 5.5,
because expanding the name is actually the *only* thing that ::class does in
that
tc depending on type doesn't really
add anything, since the output is always a string anyway, not some
type-specific thing.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ermany, and haven't added any
other translations.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
n't considered
With the "no error handling" version, this becomes moot, because it's just a
string manipulation exercise. That's how ::class currently works, apart from a
few specific cases like static::class and $someInstance::class
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ute(callback: nameof(\Acme\bar(...))]
>...
>
>I hope this helps!
Not really, I'm afraid. If I have to write out the fully-qualified name, why
would I bother with nameof() rather than just using a string?
The more I read in this thread, the less I understand what the point of
nameof() actually is
unction the user referenced, 'Acme\bar'.
Similarly, I'm not wholly clear why nameof(MyClass::method(...)) should
evaluate to "method" rather than "MyClass::method" or indeed
"Full\NamespaceOf\MyClass::method". Some more details on what exactly it
evaluates to for each
lude a definition somewhere wrapped in
function_exists.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
etter documentation to stop people confusing
deprecations for errors, and better functionality for users to choose which
messages they see.
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
.3, remove in 10.0
c) Do not deprecate
Now if the votes are a:5, b:4, c:4, we can say:
- 9 people voted for deprecation in 8.3, vs 4 against
- only 5 voted for removal in 9.0, vs 8 against
- 9 voted for removal in 10.0, vs 4 against
So we conclude that we should deprecate in 8.3, and remove in 10.0
ing, options 3 and 4 are superior to
options 1 and 2. Do you have a specific reason to prefer option 1?
Regards,
--
Rowan Tommins
[IMSoP]
On Fri, 28 Apr 2023 at 09:16, Rowan Tommins wrote:
> On a different point, I think "assert_options" is a peculiar name for
> either setting or getting a single option, and would suggest it be
> replaced with two new functions, assert_get_option and
> assert_set_option.
>
d in circles.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Fri, 28 Apr 2023 at 05:17, Alexander Pravdin
wrote:
> On Thu, 27 Apr 2023 at 07:03, Rowan Tommins
> wrote:
>
> > You have to load the value somehow; bcmath accepts strings directly, so
> > parses the values each time, which isn't very efficient; but php-decimal
> >
h variants also makes it easier for
users to find everywhere they've used it, and polyfill both variants,
rather than having to examine each.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
"band-aid"
hyperbole, though. It could give better errors, but the solution is still
"never initialise decimals from floats", and that would be true whatever
was built into PHP.
Regards,
--
Rowan Tommins
[IMSoP]
o whoever
configures PHP (the Linux distro, hosting company, etc).
That's assuming we go down the "object with efficient constructor and
operator overloading" route. If we made deeper changes to make it scalar
(which would be A LOT of work), it would be there for everyone.
Rega
t-data-types-and-values.html#sec-object-type
Regards,
--
Rowan Tommins
[IMSoP]
at impact.
(As an aside, I'd personally much rather type \ in front of functions
than maintain a long "use function" list in every file, even with the
aid of tools; but apparently I'm in a minority on that.)
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Develo
re are ways that PHP might be able to optimise for
different use cases, but the power of the autoloader being a callback
function is that it can do whatever you want it to. It doesn't even need
to involve files at all, if you don't want it to.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
( $reasonPhrase !== null ) {
$newProps['reasonPhrase'] = "Old: $this->reasonPhrase, New:
$reasonPhrase";
}
return clone $this with (...$newProps);
}
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
th {:$x, :$y, :$z};
Rather than making everything use an array or array-like syntax, I would
probably go the other way and scrap the special syntax for dynamic names,
making the whole thing look like a function call, with support for array
unpacking:
$point = clone $point with (x: $x, y
to have an example of how this looks
with the clone-with syntax.
2) How does this interact with an __clone() method? I'm guessing the
__clone() would be called first, and then the with-clause applied?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
property
references. It's a lot of extra complication to duplicate things the language
already has.
Having played with it a bit while implementing, I also like the conciseness of
objects with no explicit body at all:
$who = new class use ($firstName as string, $lastName as string) {};
echo $who->f
e parent
constructor. I think with clean errors that's a good first feature set, and
if someone comes up with an implementation for manipulating existing
constructors, that can be proposed later.
So, "watch this space", as the saying goes :)
Regards,
--
Rowan Tommins
[IMSoP]
roposed change in behaviour, so if you want a test
that passes on existing versions and fails on the current branch, just delete
the last two lines in the EXPECT section.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
our change is actually a BC break, because the examples so far
haven't convinced you?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
eone has a less ugly suggestion?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
\foo\strlen('x') should become an implicit alias for \strlen('x'), which
is apparently the current proposal.
I really like the majority of this proposal, but right now would vote
against it based on that.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing
the documentation to signpost them better is
something that can happen right now, whether we move or not.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ing, github only does
level-2 threading.
... and I wonder if others really get that people aren't just defending
e-mail because we're old and stubborn, we actually like how it works, or
at least think it has pros as well as cons.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internal
if it's the latter, migrating the entire community to a new
platform won't help - we'll still suck at introducing anyone to that
platform - and most of what we need is someone who's good with words to
update some website copy.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP R
apanese fireworks, all from people who haven't
otherwise participated in the conversation ... I'll just ignore them and
carry on.
It's certainly not a killer feature I'd uproot an entire community for.
Regards,
--
Rowan Tommins
[IMSoP]
sted users to split and
merge threads)
* Spam control
Regards,
--
Rowan Tommins
[IMSoP]
time(true) in your application to calculate the duration from
REQUEST_TIME_FLOAT to start of profiling, with all subsequent profiling
using hrtime?
Regards,
--
Rowan Tommins
[IMSoP]
https://heap.space/xref/php-src/main/SAPI.c?r=9d5f2f13#1085
[2]
https://heap.space/xref/php-src/sapi/apache2handler/sapi_apache2.c?r=4da0da7f#371
Regards,
--
Rowan Tommins
[IMSoP]
function autoloading feels more natural.
Regards,
--
Rowan Tommins
[IMSoP]
foo::function would be dependent on runtime state in a way that Foo::class is
not.
Meanwhile, the main use case for such a syntax - getting a reference to use as
a callback - is now well served by the first class callable syntax
my_function(...)
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Inte
On 11 April 2023 13:01:08 BST, Dan Ackroyd wrote:
>On Tue, 11 Apr 2023 at 09:48, Rowan Tommins wrote:
>>
>> Similarly, I think it should be possible to "unpin" a function
>> lookup with a later definition,
>
>Can you say what the technical justification f
mposer.org/doc/04-schema.md#psr-4):
> Namespace prefixes must end in \\ to avoid conflicts between similar
> prefixes. For example Foo would match classes in the FooBar namespace so the
> trailing backslashes solve the problem: Foo\\ and FooBar\\ are distinct.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
y rather inefficient.
Perhaps the "register" functions should take an optional list of namespace
prefixes, so that the core implementation can do the string comparison, and
only despatch to the userland code if the requested class/function name matches.
Thanks again for working on this!
quirks" &
"limited-quirks", JS's "use strict" - but it doesn't scale, so it's
never going to replace the genuinely hard question of how to improve a
language for new code, while limiting pain for existing code.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
aft" status rather than "In Discussion", so hasn't been
announced yet, and may not be ready for discussion.
I'll leave it up to Ilija and Larry to say whether your question is
something they know the answer to, or if it's a "known unknown".
Regards,
--
Rowan Tommins
[IMSoP]
Regards,
--
Rowan Tommins
[IMSoP]
101 - 200 of 1038 matches
Mail list logo
