Re: [PHP-DEV][DISCUSSION] Multibyte for levenshtein function

2024-10-04 Thread Tim Düsterhus
ly offer a `grapheme_*` function here or to leave this fully to userland. Best regards Tim Düsterhus

Re: [PHP-DEV] Asymmetric visibility Reflection API problems

2024-10-04 Thread Tim Düsterhus
ith a new PHP version, unless specifically marked as compatible by the author. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [Discussion] Add get_declared_enums() function

2024-10-04 Thread Tim Düsterhus
entioned this is especially true for the change to `get_declared_classes()` which would be unable to emit the deprecation notice at all! Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [Discussion] Add get_declared_enums() function

2024-10-04 Thread Tim Düsterhus
object. The same is not true for interfaces and traits, which are structures that help you build a class (including enum classes, which support both interfaces and traits). Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Policy on 3rd party code

2024-10-04 Thread Tim Düsterhus
already a much more agreeable proposal than Jim's for the reasons I quoted from your mail. Best regards Tim Düsterhus

Re: [PHP-DEV] No more RFC implementations during beta phase

2024-09-27 Thread Tim Düsterhus
igh-profile / high-impact RFCs [1] to either - vote and merge them well in advance of feature freeze (no later than April or so) - or to intentionally delay it until the first RC release of the current cycle and then vote it for the next PHP version. Best regards Tim Düsterhus [1] Rule o

Re: [PHP-DEV] No more RFC implementations during beta phase

2024-09-26 Thread Tim Düsterhus
8.4). Asymmetric visibility being voted on shortly before the freeze made me a little uneasy for that reason. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [Discussion] Using and Mentioning Third-party Packages in PHP Documentation and Web Projects

2024-09-26 Thread Tim Düsterhus
uation any *less* vague. It just makes the situation vague in a different way, because there are no guidelines regarding what is acceptable and what is not, as also mentioned by others in this RFC's discussion thread. Best regards Tim Düsterhus

Re: [PHP-DEV] VCS Account Request: ayesh

2024-09-26 Thread Tim Düsterhus
Hi Am 2024-09-25 21:26, schrieb Ayesh Karunaratne: I see the account is already approved. Unless you did not yet accept the invitation to the GitHub organization, it appears that you were not invited there yet. If that is the case, someone should send the invite. Best regards Tim

Re: [PHP-DEV] strrchr with needle with multiple characters

2024-09-19 Thread Tim Düsterhus
inting out such mistakes is exactly what the Warning / Notice facility is for. Best regards Tim Düsterhus

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

2024-09-19 Thread Tim Düsterhus
Discussion thread is here: https://externals.io/message/121969#121969 Best regards Tim Düsterhus

Re: [PHP-DEV] weird error when saving RFCs

2024-09-18 Thread Tim Düsterhus
ns I don't have accurate times, I'm afraid. Best regards Tim Düsterhus

Re: [PHP-DEV] Which IDE do you recommend for php-src development?

2024-09-15 Thread Tim Düsterhus
r happy with it. I do use gdb purely from the command line, though. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [VOTE] Transform exit() from a language construct into a standard function

2024-08-13 Thread Tim Düsterhus
not clean them up). Best regards Tim Düsterhus

Re: [PHP-DEV][Discussion] Should All String Functions Become Multi-Byte Safe?

2024-08-11 Thread Tim Düsterhus
t;). You might be interested in https://externals.io/message/119149#119149. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [VOTE] Transform exit() from a language construct into a standard function

2024-08-08 Thread Tim Düsterhus
Hi On 8/7/24 22:33, Theodore Brown wrote: I'm confused by this, since earlier in the thread Tim responded with examples showing how the behavior of exit() can still be observed and correctly handled. If that didn't address your issue, can you explain it further? It seems like right now everyo

Re: [PHP-DEV] [RFC] [VOTE] Transform exit() from a languageconstructinto a standard function

2024-08-08 Thread Tim Düsterhus
engine, the JIT and extensions have one fewer Opcode they need to deal with / take into account / test. Anything that is capable of handling functions that throw exceptions will be capable of handling the proposed exit() function. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [VOTE] Transform exit() from a language construct into a standard function

2024-08-05 Thread Tim Düsterhus
Hi On 8/5/24 18:06, Levi Morrison wrote: After thinking about this several times over the course of discussion and again now that it's in voting, I have decided to vote no. I am in favor of this change, I just think given the concerns it's best to wait for PHP 9.0 to do it. Maybe the concerns wi

Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function

2024-08-05 Thread Tim Düsterhus
relevant for testing purposes. I don't understand why you would need the special handling for testing purposes, but as outlined above you can just hardcode a check for a call to the `exit()` function if the tests cannot use the regular script end for some reason. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [VOTE] Transform exit() from a language constructinto a standard function

2024-08-05 Thread Tim Düsterhus
regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [VOTE] Transform exit() from a language construct into a standard function

2024-08-05 Thread Tim Düsterhus
Stack trace: #0 php-src/test.php(11): exit(Object(MyClass)) #1 php-src/test.php(14): a() #2 {main} thrown in php-src/test.php on line 11 MyClass::__destruct Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

2024-07-30 Thread Tim Düsterhus
sue discussing improvements to the documentation, but for reference for readers following along: https://github.com/php/doc-en/issues/3616 Please also see my previous email regarding the docs improvements I've already made: The examples for the hash() functions should now all use sha256 (ma

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

2024-07-30 Thread Tim Düsterhus
nting the convenience functionality for each algorithm separately - or as standalone functions. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

2024-07-30 Thread Tim Düsterhus
ple confusing the hashing algorithms with password key stretching algorithms then that's not a valid reason. A red warning in the documentation should aid people in clearing this confusion. No, it's about MD5 and SHA-1 being a bad choice nowadays and nevertheless being more prominently available than the alternatives. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

2024-07-30 Thread Tim Düsterhus
compatibility break, whereas a deprecation does not. Remember: The algorithms are also available by means of the hash() function (and the related functions), without emitting a deprecation, warning, error, or Exception. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

2024-07-30 Thread Tim Düsterhus
d of any other error level, because it is the least severe error level we have available: Libraries and Frameworks nowadays generally understand that deprecations are not hard errors and thus do not convert these to exceptions, but instead just direct them to a different log file / show them in th

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

2024-07-30 Thread Tim Düsterhus
d the broken algorithms from the $algo parameter explanation, leaving only 'sha256' as the opinionated example (already merged, but not yet deployed). Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

2024-07-30 Thread Tim Düsterhus
that there was no indication that the tutorials would need updating: The code continued to work without showing any warnings or errors. As long as users click the tutorial and thus see the embedded ads and advertising revenue comes in, there is no need to change anything ;-) Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

2024-07-30 Thread Tim Düsterhus
Hi On 7/26/24 15:13, Rowan Tommins [IMSoP] wrote: On Fri, 26 Jul 2024, at 12:58, Tim Düsterhus wrote: I think you are expecting a little too much from a beginner that is following "the modern PHP tutorial" if you expect them to critically question whether the tutorial is actually g

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

2024-07-26 Thread Tim Düsterhus
fs's principle, the security of the algorithm must not rely on the attacker not knowing how it's implemented. Given how prevalent constructions like the above are, an attacker could make an educated guess about how it looks like and match their own token against a precomputed table

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

2024-07-26 Thread Tim Düsterhus
cerned with in this scenario really depends on what randomness you feed it. My point was that if you already have randomness then you don't need to pair it with a hash function. You don't gain any randomness by passing it through a hash function. Just convert the randomness to a readable representation using bin2hex, base64_encode or by using Randomizer::getBytesFromString(). Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

2024-07-25 Thread Tim Düsterhus
us it is unable to generate a random UID. Whatever this code is doing can most likely be more reliably achieved in a different way. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Lazy Objects

2024-07-25 Thread Tim Düsterhus
d. Right, thank you for the clarification. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

2024-07-25 Thread Tim Düsterhus
convenient compared to hash('sha256', …). Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Lazy Objects

2024-07-25 Thread Tim Düsterhus
s it into a regular object of the proxy class, as if `newInstanceWithoutConstructor()` was used, right? Best regards Tim Düsterhus

Re: [PHP-DEV] Should PHP reserve a namespace for built-in classes?

2024-07-24 Thread Tim Düsterhus
would also avoid future namespace collisions. Not using sub-namespaces would require making the classnames overly specific, because there's some names that make sense in different domains. An example would be a `Client` or `Connection`. Best regards Tim Düsterhus

Re: [PHP-DEV] Should PHP reserve a namespace for built-in classes?

2024-07-24 Thread Tim Düsterhus
Hi On 7/24/24 19:43, Nick Lockheart wrote: What is the general feeling about reserving a namespace for PHP's built in classes? see https://wiki.php.net/rfc/namespaces_in_bundled_extensions Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

2024-07-22 Thread Tim Düsterhus
g” phrasing, because changing that would effectively result in a breaking change, because the __set() may be called in situations that were not anticipated. I would have preferred a stronger phrasing that makes it clear that the RFC authors know what they are talking about. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

2024-07-21 Thread Tim Düsterhus
after a month of not looking at it, but I'm not sure if I'll manage today. For now: Is there any implementation of this RFC? The RFC text only references the https://github.com/php/php-src/pull/9257 PR hasn't been updated since December 2022. Best regards Tim Düsterhus

Re: [PHP-DEV] Request for opinions: bug vs feature - change intokenization of yield from

2024-07-21 Thread Tim Düsterhus
omment placement are not at fault here and shouldn't bear the consequences. Best regards Tim Düsterhus

Re: [PHP-DEV] Request for opinions: bug vs feature - changeintokenization of yield from

2024-07-21 Thread Tim Düsterhus
Hi On 7/20/24 20:31, Christoph M. Becker wrote: If the tokenizer would tokenize a whole file as a single token, would that also be correct? Of course, I'm exaggerating, but The function is documented as: token_get_all() parses the given code string into PHP language tokens using the Zend e

Re: [PHP-DEV] Request for opinions: bug vs feature - change intokenization of yield from

2024-07-21 Thread Tim Düsterhus
eld containing free-form data, but still follows its defined specification of emitting the token stream as PHP sees it", the former clearly has a much larger possible impact. Best regards Tim Düsterhus

Re: [PHP-DEV] Request for opinions: bug vs feature - change intokenization of yield from

2024-07-20 Thread Tim Düsterhus
-formed PHP programs. Tools working on the token stream need to adapt and this change is no different from any other change to PHP's syntax in that regard (except that documenting the change was forgotten). Best regards Tim Düsterhus

Re: [PHP-DEV] Request for opinions: bug vs feature - change intokenization of yield from

2024-07-20 Thread Tim Düsterhus
s different thing and should in my opinion, not be allowed. As I've said: I agree that the current situation is unfortunate. But the correct solution is not "disallow comments", but "split the T_YIELD_FROM into T_YIELD T_WHITESPACE T_FROM_FOR_YIELD_FROM". Best regards Tim Düsterhus

Re: [PHP-DEV] Request for opinions: bug vs feature - change intokenization of yield from

2024-07-20 Thread Tim Düsterhus
;comments may appear where whitespace may appear", which is easy enough to explain and understand. So it makes sense to allow for comments between `yield` and `from`, but I agree that ideally those would be emitted as separate tokens. Best regards Tim Düsterhus

Re: [PHP-DEV] Request for opinions: bug vs feature - change intokenization of yield from

2024-07-20 Thread Tim Düsterhus
breaking change for them. So either the revert is not doing anything at all, or the revert is actively harmful. I do not see a situation where reverting the change is a value-add. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Lazy Objects

2024-07-18 Thread Tim Düsterhus
ess that we will not reach an agreement here and I also do not consider myself the target audience of this RFC. I'm just here to find edge cases :-) Except for the cloning semantics I cannot find any obvious problems with the described semantics. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Lazy Objects

2024-07-18 Thread Tim Düsterhus
semantics is an unrelated matter that is not relevant to this discussion. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Lazy Objects

2024-07-18 Thread Tim Düsterhus
ninitialized entity, you don't trigger a database roundtrip. Instead, you create a new object that still references the original state internally, but under a different object identity. This cloning behavior is the one we've had for more than 10 years and I think it's also the least astonishing one - at least if we consider this example as a real world trial of this principle. See above. Best regards Tim Düsterhus

Re: [PHP-DEV] Request for opinions: bug vs feature - change in tokenization of yield from

2024-07-18 Thread Tim Düsterhus
with 8.1.29 (which is the newest 8.1.x as of now). Thus the ship has effectively sailed due to the inclusion in Ubuntu 24.04 LTS as the arguably most widely used Linux distro. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

2024-07-18 Thread Tim Düsterhus
-en/pull/3571 If the deprecation is accepted, then the list of possible alternatives that are already mentioned in the RFC can be included in the documentation. Best regards Tim Düsterhus

Re: [PHP-DEV] Optional constructor body

2024-07-18 Thread Tim Düsterhus
ndard" would be splitting and cutting the quoted bits as appropriate so the context of what you are replying to is immediately visible. Just like I am doing in my email right now: I've removed everything except the specific sentence I'm replying to. Best regards Tim Düsterhus

Re: [PHP-DEV] Optional constructor body

2024-07-18 Thread Tim Düsterhus
code into the body, but also replacing the semicolon by braces, making the diff less readable. I do not think this is worth it. Best regards Tim Düsterhus

Re: [PHP-DEV] [VOTE] Correctly name the rounding mode and make it an Enum

2024-07-18 Thread Tim Düsterhus
Hi On 7/3/24 08:32, Tim Düsterhus wrote: RFC Text: https://wiki.php.net/rfc/correctly_name_the_rounding_mode_and_make_it_an_enum Discussion Thread: https://externals.io/message/123472 The RFC has been accepted unanimously with 34 (yes) to 0 (no) votes. I'll now make the final adjustmen

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

2024-07-15 Thread Tim Düsterhus
l migration docs, helping users making an educated choice for an alternative. Unfortunately is no one-size-fits-all solution to the problem of generating an unique string. Best regards Tim Düsterhus [1] This includes uniqid(), rand(), mt_rand(), lcg_value(). random_bytes() and random_int() are fine. [2] https://github.com/paragonie/random_compat

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

2024-07-15 Thread Tim Düsterhus
can also be considered "unsafe." What people usually mean by this is in the context of encryption, and in those cases it is unsafe, but in the context of non-encryption, usage of truncated larger hashes is just as unsafe. I'm afraid I don't understand what you are attempting to say here. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

2024-07-15 Thread Tim Düsterhus
e goal of the proposal is the anticipated positive downstream effects in overall ecosystem safety and simplified learning curve for new PHP developers. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Lazy Objects

2024-07-15 Thread Tim Düsterhus
ain a library that already provides this resetting capability because there are valid use cases for them. That'd be a failure to address the needs of userland on the topic to me. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Lazy Objects

2024-07-15 Thread Tim Düsterhus
at can safely be combined with the `reset*()` methods: Anything special the user did to construct the object would be reverted, so the user might as well rely on the default construction logic of the factory then. What am I missing? Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Lazy Objects

2024-07-15 Thread Tim Düsterhus
if I follow this example. With the native support for lazy objects there should no longer be a need for code generation, no? Testing that PHP works correctly in your own test suite is not a value-add, PHP has its own tests for that. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Lazy Objects

2024-07-11 Thread Tim Düsterhus
ence with the reasoning. Something like: Properties are not initialized to their default value yet (they are initialized before calling the initializer). As an example, this has an impact on the behavior of an (array) cast on uninitialized objects and also when the default value is based on a constant that is not yet defined when creating the lazy object, but will be defined at the point of initialization. Best regards Tim Düsterhus

Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute

2024-07-10 Thread Tim Düsterhus
cause to the best of my knowledge nothing else uses that (except for git tags). You can find the discussion about the `$since` property in the first PR at https://github.com/php/php-src/pull/11293#discussion_r1647339607, if you want additional context. Best regards Tim Düsterhus

Re: [PHP-DEV] Negatively Voted Notes

2024-07-10 Thread Tim Düsterhus
andom I can see how some of the bad comments could serve as good data for new warnings to add to the documentation. Randomness is pretty unintuitive and it's easy to make conceptual mistakes that other folks made before. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [Discussion] Allow int type argument to BCMath function

2024-07-10 Thread Tim Düsterhus
easily and because they to not experience implicit rounding. I do not particularly care whether or not 'int' is accepted or not for that reason, but I care about 'float' not being accepted. So perhaps it's best to accept neither as you suggested. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Property Hook improvements

2024-07-10 Thread Tim Düsterhus
the RFC page: You didn't remove the "(use today's date here)" placeholder at the top. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [Discussion] Fix up BCMath Number Class / Change GMP bool cast behavior

2024-07-09 Thread Tim Düsterhus
ly vote in favor of both votes. Best regards Tim Düsterhus

Re: [PHP-DEV] ext/gd adding imagecompare

2024-07-09 Thread Tim Düsterhus
or ideally be replaced by a proper enum or so. Best regards Tim Düsterhus

Re: [PHP-DEV] ext/gd adding imagecompare

2024-07-09 Thread Tim Düsterhus
enum ImageDifference { case Height; case Width; case AlphaChannel; // or: case Transparency case Interlacing; // ... } Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [Discussion] Allow int type argument to BCMath function

2024-07-09 Thread Tim Düsterhus
utput is a string, the int->string conversion would only happen at the inputs. The performance cost should be fully acceptable and this looks like a premature micro-optimization. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [Discussion] Allow int type argument to BCMath function

2024-07-09 Thread Tim Düsterhus
would need to be made explicit with a cast. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [Discussion] Add bcdivmod to BCMath

2024-07-05 Thread Tim Düsterhus
() - openssl_csr_export() - socket_getpeername() And for all of those it would arguably a better API to just return the value and throw an Exception on failure. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Lazy Objects

2024-07-05 Thread Tim Düsterhus
lready does this and is force-inlined, but it might remove the branch with the call to `instanceof_function_slow()`. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Lazy Objects

2024-07-05 Thread Tim Düsterhus
value before calling the initializer? For ghost objects the behavior is clear, just not for proxies. 2. > Properties are not initialized to their default value yet (they are initialized before calling the initializer). I see that you removed the bit about this being not observable. What is the reason that you removed that? One possible reason that comes to my mind is a default value that refers to a non-existing constant. It would be observable because the initialization emits an error. Are there any other reasons? Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Property Hook improvements

2024-07-05 Thread Tim Düsterhus
king, though and I agree with the examples he gave to point out how this is a bad idea. Best regards Tim Düsterhus

Re: [PHP-DEV] [VOTE] Correctly name the rounding mode and make it an Enum

2024-07-05 Thread Tim Düsterhus
Hi On 7/3/24 08:32, Tim Düsterhus wrote: RFC Text: https://wiki.php.net/rfc/correctly_name_the_rounding_mode_and_make_it_an_enum Discussion Thread: https://externals.io/message/123472 I have just added a link to the implementation of the enum and the changes to `round()` to the RFC. Saki

[PHP-DEV] [VOTE] Correctly name the rounding mode and make it an Enum

2024-07-02 Thread Tim Düsterhus
FC Text: https://wiki.php.net/rfc/correctly_name_the_rounding_mode_and_make_it_an_enum Discussion Thread: https://externals.io/message/123472 Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Property Hook improvements

2024-07-01 Thread Tim Düsterhus
y unsupported, this could very well be added with PHP 8.5, allowing folks to really think about the implications and how it interacts with stuff. That's a "no" from my side. Best regards Tim Düsterhus PS: Small typo: '$this-dbApi->loadCategory($this->categoryId);', '>' missing there after 'this-'.

Re: [PHP-DEV] [RFC] [discussion] Correctly name the rounding mode and make it an Enum

2024-07-01 Thread Tim Düsterhus
me in. Oh well. Saki and I are happy with the RFC as it is and we also checked with some folks with a background in maths to see if they would make any further changes, which they answered they would not. We plan to to open the vote on Wednesday, July 3rd. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [discussion] Correctly name the rounding mode and make it an Enum

2024-07-01 Thread Tim Düsterhus
es just for this case does not appear useful. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [Discussion] Add bcdivmod to BCMath

2024-06-30 Thread Tim Düsterhus
supplementary data by an out-parameter. The main result ("does the RFC match") is returned regularly. - all the sorts These do not return anything, they modify the array in-place, which is something different than returning something. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Static class

2024-06-30 Thread Tim Düsterhus
t that will not cause sadness 3 years down the road. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Static class

2024-06-30 Thread Tim Düsterhus
runs on PHP versions that will reliably enforce all the constraints, preventing this gotcha during a PHP version upgrade. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [Discussion] Add bcdivmod to BCMath

2024-06-30 Thread Tim Düsterhus
der of values matches the words in the method name. First the result of 'div', then the result of 'mod'. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC][Discussion] Enhance JSON error messages

2024-06-30 Thread Tim Düsterhus
fo() for easier programmatic access of the important bits can still be considered, but would not need an RFC either from my point of view. It's a simple and obvious addition. Those can be done without an RFC, unless someone complains. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Lazy Objects

2024-06-30 Thread Tim Düsterhus
;obj1'); $r->resetAsLazyProxy($obj1, function () use (&$obj2) { $obj2 = new Obj('obj2'); return $obj2; }); $r->resetAsLazyProxy($obj2, function () { return new Obj('obj3'); }); var_dump($obj1->name); // what will this print? Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Lazy Objects

2024-06-30 Thread Tim Düsterhus
Hi On 6/30/24 15:08, Tim Düsterhus wrote: I've read the updated RFC and it's still not clear to me that returning an arbitrary “actual instance” object is sound. Especially when private properties - which for all intents and purposes are not visible outside of the class - are involved

Re: [PHP-DEV] [RFC] Lazy Objects

2024-06-30 Thread Tim Düsterhus
uctor as a workaround, just as Benjamin did: https://externals.io/message/123503#123525 Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Lazy Objects

2024-06-30 Thread Tim Düsterhus
e. the mangled B::$foo property)? Now you might say that B does not have the same properties as A and creating the proxy is not legal, but then the addition of a new private property would immediately break the use of the lazy proxy, which specifically is something that private properties should not be able to do. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] [discussion] Correctly name the rounding mode and make it an Enum

2024-06-30 Thread Tim Düsterhus
uses it to describe which of the ”legacy” rounding mode constants are equivalent to the proposed enum cases. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC][Discussion] Enhance JSON error messages

2024-06-30 Thread Tim Düsterhus
following along, I've commented on the PR. I think that improving the existing messages is the right choice, not adding new functions that users will need to remember to use. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

2024-06-30 Thread Tim Düsterhus
er being a required parameter or a well-designed (object-oriented) API, such as the one provided by T-Regx: https://github.com/t-regx/T-Regx?tab=readme-ov-file#prepared-patterns But as Gina said, this is something for another discussion. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Static class

2024-06-27 Thread Tim Düsterhus
ax for the clone-with RFC that has since been replaced by array-style syntax that should be immediately understandable by any PHP programmer. PHP should continue to look and feel like PHP. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Static class

2024-06-27 Thread Tim Düsterhus
want static classes", but if they use an attribute instead of a keyword, then it's going to be a clear "no". See also my email in response to Ayesh. Best regards Tim Düsterhus PS: Can you please cut the quoted parts to a minimum instead of including the original email in

Re: [PHP-DEV] [RFC] Static class

2024-06-27 Thread Tim Düsterhus
decides to declare classes as static. It should not. See: readonly classes. I also believe that static classes should be implictly final. Given that no objects of such a class can exist, they cannot be exchanged by a different class anyways and inheritance is not meant for code reuse. Best regards Tim Düsterhus

Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute

2024-06-27 Thread Tim Düsterhus
ement exactly the semantics that were decided in the RFC. The implementation is already be complete and is currently pending JIT review by Dmitry. Assuming no change requests during the review I'll make a final cleanup pass and then it should be ready to merge. Anything that is not in the RFC will (need to) be part of a separate PR. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

2024-06-27 Thread Tim Düsterhus
century ago. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

2024-06-27 Thread Tim Düsterhus
s anywhere? Pointing towards the documentation is not an excuse for bad API design. Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

2024-06-27 Thread Tim Düsterhus
meter to `2` to prevent further processing from happening after encountering the first delimiter. Best regards Tim Düsterhus

Re: [PHP-DEV] Re: [RFC] [Vote] #[\Deprecated] attribute

2024-06-25 Thread Tim Düsterhus
ad on the implementation PR then: https://github.com/php/php-src/pull/11293#discussion_r1647339607 Best regards Tim Düsterhus

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

2024-06-25 Thread Tim Düsterhus
their own pace and for both uniqid() and md5()/sha1() there is a drop-in replacement provided in the RFC that is guaranteed to work with PHP 7.4+. Best regards Tim Düsterhus

  1   2   3   4   5   6   >