happier spending the
time reading an RFC that is five times as long, but clearly defines the
entire behavior, than reading an RFC that leaves many open questions
that will end up being "implementation-defined" rather than fully
thought-through.
Best regards
Tim Düsterhus
[
ght scope by the user. This should not be an issue when the
initializer just calls a public constructor.
Please clarify the interaction with visibility in the RFC.
Best regards
Tim Düsterhus
// breaks
$o->foo() calls B::foo() in both cases here, as $o is always the proxy
object. We need to double check, but we believe that this rule doesn't
break LSP.
I don't understand what happens with the 'A' object then, but perhaps
this will become clearer once you add the requested examples.
Best regards
Tim Düsterhus
ncompatible Changes
There a technicality: The `ReflectionLazyObject` class name will no
longer be available to userland.
Best regards
Tim Düsterhus
#Comparison_of_approaches_for_rounding_to_an_integer
Hope this helps.
Best regards
Tim Düsterhus
I believe that the case of making a property public-write, private-read
is best left to a virtual set-only hook.
Best regards
Tim Düsterhus
you have something useful to add. You don't need a Wiki account
for that.
The approved Wiki account is only required to edit pages on the Wiki,
i.e. to create your own RFC. Do have already have something in mind?
Best regards
Tim Düsterhus
], the existing `ceil()`
and `floor()` functions are redundant with the capabilities of
`round()`. Anyone who newly learns PHP would get all the functionality
by just using `round()` together with one of the self-explanatory
rounding modes provided by the proposed `RoundingMode` enum.
Best regards
Tim
to
how they interact with negative numbers. I find “Ceiling” and “Floor”
equally unclear and would likely need to look up their behavior when
facing negative numbers in the documentation.
Best regards
Tim Düsterhus
ated based on their naming.
That would make it clear that those two are closely related and also
that all the modes starting with 'Half' would be the ones that are only
relevant if the last digit is 5, whereas the others act unconditionally.
Best regards
Tim Düsterhus
[1] Possibly with an 'Towards' inser
f a script
dies due to an uncaught Exception, due to exceeding the memory limit, or
simply terminates by successfully running until the finish, without
explicitly calling exit()?
Best regards
Tim Düsterhus
ind of
placeholders in a standardized fashion.
Best regards
Tim Düsterhus
be performed on $foo and
would be able to syntax highlight the visibility definition properly and
they would also know how to autoformat it, without needing to add
support for the new keyword.
Best regards
Tim Düsterhus
operty::setValue()` works.
Best regards
Tim Düsterhus
a
script that fails, e.g. due to an uncaught exception or due to reaching
the memory limit?
Best regards
Tim Düsterhus
not a fan of implicit. I like my code to be easy to read and
reason about, not easy to write (and hard to read).
Best regards
Tim Düsterhus
probably to late to change it.
Best regards
Tim Düsterhus
”
representation to store in the backed value feels semantically incorrect
to me.
Best regards
Tim Düsterhus
[1] Except possibly to alias an enum case for BC purposes.
Tim Düsterhus
Hi
On 5/22/24 02:48, Aaron Piotrowski wrote:
Perhaps not as clean and easy as the functionality being built-in, but it gets
the job done.
I would suggest to use the built-in functionality then.
enum cases are literally just class constants, thus you can access them
via the `constant()`
Hi
On 5/22/24 01:31, Larry Garfield wrote:
A unit enum isn't serializable, by design.
A unit enum is perfectly serializable: https://3v4l.org/Mf9Ou
. In fact this is how the current implementation works:
It doesn't actually support arrays yet, it just borrows the syntax of an
array, because it more naturally extends to supporting arrays in the future.
Best regards
Tim Düsterhus
[1] See also my previous email: https://externals.io/message
body to make that clearer.
Best regards
Tim Düsterhus
.
Best regards
Tim Düsterhus
and we move on with life.)
If a string is passed, the exit_status is left untouched [1]. In
practice this should always result in an exit status of 0, because I
can't see how the exit_status would be non-zero before `exit("foo");`
successfully executes.
Best regards
Tim Düsterhus
expression.
- The include family is an expression and requires a single non-empty
expression.
Best regards
Tim Düsterhus
PS: Today I learned that echo and print are not aliases.
Hi
On 5/8/24 15:40, Gina P. Banyard wrote:
Let me know what you think.
The fewer not-actually-a-function functions, the better. I don't have
any remarks and I'm in favor.
Best regards
Tim Düsterhus
in favor of the RFC and implementation the way it currently looks
like. Implementation just needs some additional test cases, e.g. to
ensure the callback is not called after an item has been found and to
ensure proper behavior when an Exception is thrown.
Best regards
Tim Düsterhus
my area of expertise), not the API
surface / the methods that are exposed. As an example, my concern about
the `format()` method has been left unresolved.
As such, I'm also voting "no", because I feel like the exposed API is
worse than it could be, but I also support the concept in
Hi
On 4/22/24 15:26, Tim Düsterhus wrote:
Please find the following resources for your references:
RFC Text: https://wiki.php.net/rfc/class-naming-acronyms
Discussion Thread: https://externals.io/message/122975
Pre-RFC Discussion Thread: https://externals.io/message/120959
Related discussion
ext: https://wiki.php.net/rfc/class-naming-acronyms
Discussion Thread: https://externals.io/message/122975
Pre-RFC Discussion Thread: https://externals.io/message/120959
Related discussion in PHP-FIG:
https://github.com/php-fig/per-coding-style/issues/83
Best regards
Tim Düsterhus
Hi
On 4/9/24 21:49, Tim Düsterhus wrote:
However I'm not sure if adding new array functions piecemeal is the
right choice at this point. array_any and array_every are conceptually
very similar to array_find and are missing as well. In fact
array_any($cb, $array) = array_find($cb, $array, true
to pass to the callback.
Not that I claim that the `$mode` parameter is a good idea from the
typing perspective for static analysis tools, it probably isn't.
Best regards
Tim Düsterhus
d not be abbreviated
at all.
I've adjusted the examples [1], thank you for pointing this out!
Best regards
Tim Düsterhus
[1]
https://wiki.php.net/rfc/class-naming-acronyms?do=diff%5B0%5D=1712419286%5B1%5D=1713553737=sidebyside
Hi
On 4/5/24 19:00, Tim Düsterhus wrote:
RFC: https://wiki.php.net/rfc/class-naming-acronyms
Previous ML discussion: https://externals.io/message/120959#120959
Related discussion in PHP-FIG:
https://github.com/php-fig/per-coding-style/issues/83
The two weeks of discussion are over now
repository are
cleaned up as a follow-up to the policies RFC.
Best regards
Tim Düsterhus
ut a broader concept for the namespace, we
probably should not introduce one.
Best regards
Tim Düsterhus
it will have.
Indeed. See my email in the previous pre-RFC discussion thread:
https://news-web.php.net/php.internals/121057
Best regards
Tim Düsterhus
, borrowing syntax where useful and inventing new syntax where the
existing syntax does not provide anything.
It's a clear improvement over the status quo of __get() and __set(),
especially from a third-party tooling perspective. I'm in favor.
Best regards
Tim Düsterhus
, though, but to be applicable for multiple
functions. (I did not go looking to see if such functions exist.)
Whoops, I accidentally a word in that paragraph, thank you.
It should have read "each binary parameter that is NOT semantically true
and false".
Best regards
Tim Düsterhus
lts. As
an RFC author I think it would be useful information to me: Did some
folks not vote because they missed the RFC or because they are happy
with either result?
Best regards
Tim Düsterhus
not sure
whether adding a array_find_key companion would be confusing or not.
Best regards
Tim Düsterhus
this an error would be appropriate. Generally speaking:
Removing errors later is always possible if we find out that an
operation is safe and well-defined. Adding an error if we find out that
an operation is unsafe will result in breaking changes, thus we should
get it right on the first try.
Best regards
Tim Düsterhus
ions can be proposed
if it is desired.
Best regards
Tim Düsterhus
to set up
signing, even without actually enforcing it on GitHub.
Best regards
Tim Düsterhus
nges, it should list that the
BcMath\Number class will no longer be available to userland.
Best regards
Tim Düsterhus
lowed the precedent set by ext/random.
Best regards
Tim Düsterhus
L + SSO
GPU + CUDA
ARM + CPU
Apologize the focus on cryptographic concepts, but these case to my mind
most easily :-)
Best regards
Tim Düsterhus
;BCMath”.
With the current policy it should be "BCMath", if my RFC passes it
should be "BcMath". I think Bcmath would be fine as well, if you
consider the extension name to be a single word.
Best regards
Tim Düsterhus
step would be to rephrase the
text so that it reads like a policy document, instead of an RFC. The wording is
currently exactly as in the used RFCs, without modification.
That has not yet happened, though.
Best regards
Tim Düsterhus
ase would be enabled by allowing inheritance without
being subtly broken by being unable to override the native operations?
As I've said yesterday in Stack Overflow chat: "Operator overloads
through a backdoor are even worse than actual operator overloads".
Best regards
Tim Düsterhus
https://github.com/thephpleague/flysystem/blob/3.x/src/AwsS3V3/S3ClientStub.php
Best regards
Tim Düsterhus
object,
possibly even lacking the necessary information to properly fix up the
state, because it does not know which operations lead to the state.
Best regards
Tim Düsterhus
Best regards
Tim Düsterhus
ion and impaired vision alike
(i.e. PDOODBC and XSLRR).
From my personal experience as a human with regular vision (not even
glasses), the variant of treating acronyms as regular words is much
easier to parse.
Best regards
Tim Düsterhus
discussion: https://externals.io/message/120959#120959
Related discussion in PHP-FIG:
https://github.com/php-fig/per-coding-style/issues/83
I'd like to thank Larry and Niels for proof-reading the RFC and making
direct wording improvements (check the edit history for details).
Best regards
Tim
of the stricter checks, instead of relaxing the checks for
internal functions. The previous RFC showcases multiple examples where
it found bugs that likely were introduced during refactoring.
Best regards
Tim Düsterhus
hoice and then being unable to
change it, due to backwards compatibility or interoperability concerns.
PHP has enough gotchas as it is, so for any new API making it a *great*
API, not just an *okay* API should be part of the consideration. APIs
within PHP need to survive for 10+ years.
Best regards
Tim Düsterhus
);
}
This use case would be much better solved in a generic way using
something like this "Extension Methods" proposal:
https://externals.io/message/118395#118395
Best regards
Tim Düsterhus
history should folks be interested
in what has actually changed.
Another tip regarding Wiki syntax: By using instead of the
code examples will get syntax highlighting, making them more readable.
Best regards
Tim Düsterhus
of support.
I think it would be reasonable to consider deprecating passing extra
arguments to a non-variadic function.
Best regards
Tim Düsterhus
* of the
function and likely also requires adjustments in child classes when
newly introduced in a parent class or interface.
Thus it is part of the function's API and thus should be part of the
regular signature and not the attribute-based metadata.
Best regards
Tim Düsterhus
) requires an RFC. It's a bugfix, a bugfix
with a slightly larger observable impact than other bugfixes.
Best regards
Tim Düsterhus
of an attack.
Best regards
Tim Düsterhus
rent commit instead. Likewise the gzip
call does not have the -n flag and thus also embeds a timestamp into the
.tar.gz archive.
There are probably further bits that are not reproducible yet.
Best regards
Tim Düsterhus
[1] https://github.com/php/php-src/pull/10613 and
https://github.com/php/php
rfc
Best regards
Tim Düsterhus
Hi
On 3/13/24 17:06, Remi Collet wrote:
Use case: for ARGON2 password hashing
see https://github.com/php/php-src/pull/13635
It may seems ugly to add and remove th padding char
Is a RFC needed for such a minor feature ?
Previous related discussion:
be helpful
Where should that be? in the "Introduction" section? or the "Proposal"
section? (or elsewhere?)
With the current structure of the RFC I believe it would fit best within
the Proposal section.
Best regards
Tim Düsterhus
cussion period is starting now. This will
ensure it will pop up as a fresh email for the folks who already ignored
the subthread, because they were not interested in the pre-RFC
discussion while stuff is still in flux.
Best regards
Tim Düsterhus
sleep for that exact somefloat value in the face of
interrupts. Simple RFC, simple voting choice.
Lastly, I see that the RFC still is in Draft stage. Don't forgot to open
up a dedicated explicit discussion thread once you move it into the
"Discussion" phase.
Best regards
Tim Düsterhus
Hi
On 2/27/24 18:49, Rowan Tommins wrote:
This is a test e-mail from a subscribed GMail address, to see if the
"451: Temporary lookup failure" errors are now resolved.
Email successfully received, let's see whether my response is delivered
back to you via the list.
Best r
projects like externals.io).
This is false. There is an official web-accessible archive of the list:
https://news-web.php.net/php.internals
Best regards
Tim Düsterhus
is not the only project using them. The
Linux kernel successfully uses them, the HAProxy project does as well
and so does Debian.
Best regards
Tim Düsterhus
willing to do so if the
consensus is that it would be beneficial, but want to ask before putting in the
effort.
Calling it hooks is fine and allows for future extension without
renaming, should the need arise.
Best regards
Tim Düsterhus
al
brevity, the inverse is not true and I believe for such a semantically
complex feature, having clear and syntax syntax would be beneficial.
Best regards
Tim Düsterhus
https://externals.io/message/118896#118896
Best regards
Tim Düsterhus
in the past,
unfortunately without much success so far.
Best regards
Tim Düsterhus
thing the 'a' within the SPF record could be removed, because
that's the HTTP box on DigitalOcean.
Best regards
Tim Düsterhus
if it is emitted by a handle or a multihandle: This
could be a CurlConnectException (or possible a namespaced
Curl\ConnectException).
Best regards
Tim Düsterhus
/promote_php_foundation
Just a quick note that the "header section" in the RFC needs some
cleanup. The "(use today's date here)" bit should be removed; and the
Status be changed to "Under Discussion".
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing Lis
.
Let me know what you think, especially regarding the type issues.
Will the classes be made `final` if they are no longer aliases? That
should (hopefully) make similar changes somewhat easier in the future.
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
headers (e.g. x-powered-by, if enabled).
Best regard
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
.
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Hi
On 11/15/23 20:03, Tim Düsterhus wrote:
On 11/15/23 18:41, Daniil Gentili wrote:
I've created the RFC, I'd be more than glad to receive feedback:
https://wiki.php.net/rfc/final_anonymous_classes
The official start of the discussion period should likely be announced
in a separate thread
es final by default, but don't care about whether
there is the escape hatch or not and thus would vote for all 3 options.
(I'm happy to repeat that above paragraph in the new thread, once you
create it, but this gives you some time to think about it already)
Best regards
Tim Düsterhus
egisterphpfunctions.php, what's
the difference between 'php:function()' and 'php:functionString()'?
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Should this read: "before beta 3 is tagged"? An RFC could be merged
after the tag and before the release, and then there would only one
remaining Beta for it.
- 4 RC - real feature freeze without any ABI or API breaks
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime D
code.
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
and also the 'unserialize()'s 'S' tag' stub.
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Hi
On 10/24/23 20:00, Máté Kocsis wrote:
It is a ranked choice poll (following STV) and voting is open until
2023-10-07 18:00:00 UTC.
I assume this should read 2023-**11**-07? This would match the 14 days
for regular votes.
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime
to decide if the behavior is correct, especially since one of the
outputs indicates an uint64 underflow (18446744073707454792) somewhere.
However I'd first like to gauge some opinions before spending more time
on investigating that.
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime
_find()' and I would be in favor of it, with the
caveat that I would want it to work with arbitrary iterables.
See this previous thread regarding that topic:
https://externals.io/message/118896#118896
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsub
ifferent ones with
inverted parameter order. And yes, I realize that this would require
function overloading.
I would be in favor of allowing writing binary functions in infix
position to allow stuff like '($foo bcadd 5)', because I can see how
that is more readable than `bcadd($foo, 5)`
Bes
. It is precisely because of the memory issue that PHP's
existing POST handler writes files to disk, instead of leaving their
content available through an entry in $_FILES.
To clarify: `php://temp` spills over to disk at a certain size (2 MB by
default).
Best regards
Tim Düsterhus
--
PHP Internals
deprecation RFC for PHP 8.4:
https://wiki.php.net/rfc/deprecations_php_8_4
best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
that they should
"never" use a function is not good developer experience.
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
classes are final?
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Hi
On 10/16/23 10:34, Christian Schneider wrote:
Am 15.10.2023 um 19:24 schrieb Tim Düsterhus :
Making getFloat(float $min = 0.0, float $max = 1.0, IntervalBoundary $boundary =
IntervalBoundary::ClosedOpen) would seemingly make it legal to call
->getFloat(0.5), which I consider to be wo
PHP's API for most of my applications, because
it's much less boilerplate. It also avoids constructing many short-lived
objects [1]: You can just throw both the Engine and Randomizer into your
dependency injection container.
Best regards
Tim Düsterhus
[1] I expect the performance impa
ery
specialized feature that only few developers will care about. Making a
breaking change late in the release process will have a much smaller
impact to existing documentation / blog articles / feature videos / etc.
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing L
1 - 100 of 403 matches
Mail list logo
