Re: [PHP-DEV] Filesystem path APIs
On Dec 8, 2023, at 09:13, Pierre Joye wrote: > if any of them could be a easy win, relative path resolver without checking > its existence would be one. It is available internally but the existence > check option is not exposed. Are you thinking of realpath()? That also expands symbolic links, which wouldn't be desirable for abstract path manipulation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Filesystem path APIs
On Fri, Dec 8, 2023, 3:44 PM Max Semenik wrote: > On Wed, Dec 6, 2023 at 10:20 PM Niels Dossche > wrote: > > > Hi internals > > > > I'd like to start a pre-RFC discussion about filesystem path APIs in PHP. > > The reason I bring this up is because of this recent feature request: > > https://github.com/php/php-src/issues/11258 > > > > The feature request is about the following: > > We already have some functions to work with paths in PHP, e.g. basename, > > dirname, realpath. > > We do not have some common path APIs that you can find in other languages > > like: path_join to join paths and path_normalize to normalize paths. > > > > We have a lot of commonly used functionality that's successfully fulfilled > by Composer packages - does this really have to be core functionality? > if any of them could be a easy win, relative path resolver without checking its existence would be one. It is available internally but the existence check option is not exposed. >
Re: [PHP-DEV] Filesystem path APIs
Hi David On 08/12/2023 10:08, David CARLIER wrote: > I think these would be great additions to PHP as working with paths and > files is a core part of any programming language. > > > Seems like it, is there an argument to be made to, let's say, in the > performance side ? A native implementation is going to be faster than an implementation in userspace. However, I don't think that matters because the performance is likely dominated by the I/O you do after constructing a path. You'd need to construct a large number of paths before you notice anything I guess. Cheers Niels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP test coverage
Hi On 08/12/2023 17:04, Vinicius Dias wrote: >> The code coverage report can be found at >> https://app.codecov.io/github/php/php-src > > Ah, perfect. Thank you for sharing. I will take a closer look after > work, but something seems weird to me. Here[1] you see that > ctype_alpha seems to be uncovered, but here[2] we can see that it's > tested. > > [1]: > https://app.codecov.io/github/php/php-src/blob/master/ext%2Fctype%2Fctype.c#L112 > [2]: > https://github.com/php/php-src/blob/master/ext/ctype/tests/ctype_alpha_basic.phpt You'll see this kind of stuff with macros. The coverage report shows "partially covered" code as uncovered due to a limitation. In this particular example, the parameter parsing code failure isn't tested, so it marks the whole macro as untested. You'll see this many times in the PHP codebase. Also for example for RETURN_THROWS: because that macro performs an assertion it's always in red because the assertion isn't hit in our testing (and that's a good thing because if it were hit then it means there's a bug). Kind regards Niels > > >> I will have a look, the page overall looks like it could need some love ;-) >> In the meantime if you are interested in writing tests, I once wrote a blog >> post about that topic at >> https://dev.to/realflowcontrol/growing-the-php-core-one-test-at-a-time-4g4k > Ah, that's great. Thank you for that! :-D > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP test coverage
> The code coverage report can be found at > https://app.codecov.io/github/php/php-src Ah, perfect. Thank you for sharing. I will take a closer look after work, but something seems weird to me. Here[1] you see that ctype_alpha seems to be uncovered, but here[2] we can see that it's tested. [1]: https://app.codecov.io/github/php/php-src/blob/master/ext%2Fctype%2Fctype.c#L112 [2]: https://github.com/php/php-src/blob/master/ext/ctype/tests/ctype_alpha_basic.phpt > I will have a look, the page overall looks like it could need some love ;-) > In the meantime if you are interested in writing tests, I once wrote a blog > post about that topic at > https://dev.to/realflowcontrol/growing-the-php-core-one-test-at-a-time-4g4k Ah, that's great. Thank you for that! :-D -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][Under discussion] RFC1867 for non-POST HTTP verbs
Hi Sam >> On Fri, Oct 6, 2023 at 3:44 PM Ilija Tovilo wrote: >> > https://wiki.php.net/rfc/rfc1867-non-post On Thu, Dec 7, 2023 at 6:04 PM Sam I wrote: > > Hey, I'm not sure if this is bikeshedding, but the concept of parsing bodies > for non-POST requests lands really close to a proposal for adding a QUERY > method to the HTTP standard. > Draft: > https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-safe-method-w-body > Discussion: > https://github.com/httpwg/http-extensions/labels/safe-method-w-body > > It's meant to address the recent need for complex querying (GraphQL / Elastic > Search) that necessitates using POST but loses the default caching of GET. > I think this RFC could serve as the groundwork for supporting QUERY if it's > extended to other MIME types in the future as Larry suggested. But QUERY > probably still has years to go before there is a consensus on it (I think > it's been talked about for 6+ years now) Looking at the RFC, it doesn't seem like multipart is an intended format for QUERY requests. application/x-www-form-urlencoded is intended and should work as-is with request_parse_body(). Parsing anything other than multipart and form-data is possible, but not at all related to QUERY (and IMO not desirable). You can implement a QUERY endpoint in PHP today (if your web server supports it) by reading from php://input. It's worth noting that PHPs built-in server does not support custom HTTP methods and will return a 501. I don't think there's anything actionable here. Please clarify if I'm missing something. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
On Thu, Dec 7, 2023 at 11:36 PM G. P. B. wrote:
- Objects are always casted to true, GMP(0) will equal to true.
>>
>
> This is incorrect, GMP object do _not_ support casts to bool
> See https://3v4l.org/LHpD1
>
This is weird. Any PHP user would expect that a zero number can be easily
casted to boolean false. This is also why I think we need a scalar decimal
type.
>
>> It works the same as "float" in terms of its usage and type casting
>> except
>> for one thing. Float value can be passed to a decimal argument or
>> typecasted with a warning like "Float to decimal conversion may incur
>> unexpected results".
>>
>> Decimal to float conversion is allowed and smooth:
>>
>> function f (float $value) {}
>>
>> f(0.2);
>>
>> f(0.2d); // allowed with no warnings
>>
>
> I disagree with this part, floats can not represent decimal values
> properly e.g.
> $f1 = 0.1;
> $f2 = 0.2;
> $f3 = 0.3;
> var_dump($f1 + $f2 === $f3);
>
will return false.
> As such, floats are not at all compatible with decimals.
>
Yes, I know that. I mentioned that we can not convert float to decimal
without an intermediate value where we apply rounding and get a
human-readable value in some representation (string or whatsoever).
My intention was to provide implicit conversion with warnings because I
guess that the majority of end users will expect that numeric scalar types
are interoperable. To not make them scared and point them to issues in
their code instead of slapping their hands immediately when they run
something that is not so correct.
> Moreover, the whole point of adding a warning when implicit conversions
> from int to float happen was to be able to warn before elevating the
> warning to a TypeError.
>
Sorry, I'm not aware of issues of converting ints to floats. Are there any
issues? I understand the issue of the backward conversion, but not the
forward one. Could you add details here?
> Therefore, introducing behaviour that warns instead of throwing a
> TypeError is already a no-go from my PoV.
>
I'm okay with TypeErrors for float to decimal conversions as well. This is
not a key point of my proposal. If the community prefers errors instead of
warnings - that's also fine.
Literal numbers in the code are converted to floats by default. If
>> prepended by the "(decimal)" typecast, the decimal result is produced
>> without an intermediary float.
>>
>
> This behaviour is rather suboptimal, I'd rather have literals be decimals,
> as decimals to floats should always be a reasonable implicit coercion
> considering we already do int to float.
>
Is it optimal to perform conversions on every fractional literal? This is
also not a key point for me and I'm okay with any implementation that the
internals community prefers.
> New declare directive "default_decimal" is added. When used, literals and
>
>> math operations return decimal by default instead of float. This is to
>> simplify creating source files working with decimals only.
>>
>
> Please no, no new declare directives that affect engine behaviour.
> Strict types was already a mistake because of this IMHO.
>
I didn't know that the strict types directive was a mistake. My intention
is to be able to write clean all-decimal units of code and not break the
backward compatibility. The old code should work as it was before. At the
same time, there are use cases when the whole class/project should be
written with decimals only. As a user, I want to do that without complex
language structures and excessive typehints or explicit conversions. The
all-decimal code should be as clean as it is now with floats. This is why
I proposed this directive. Can you suggest something better to achieve the
same?
> New language construct "as_decimal()" is added to produce decimal math
>> results for literals and math operations instead of float without
>> intermediary float:
>>
>> $var = 5 / 2; // returns float 2.5
>> $var = as_decimal(5 / 2); // returns decimal 2.5
>>
>> This is a kind of "default_decimal" for a specific operation.
>>
>
> Again, this should return a decimal instead IMHO.
>
While it will work from the logical perspective, additional conversions
from decimal to float may incur performance issues in the existing code
that relies on floats only. Again, my intention here is to not break
backward compatibility and not introduce performance issues to the existing
code.
>
>
>> If mixed float and decimal operands are used in a math operation, decimal
>> is converted to float by default. If "default_decimal" directive or
>> "as_decimal()" construct is used, float is converted to decimal (with a
>> warning):
>>
>> $f = (float) 0.2;
>> $d = (decimal) 0.2;
>>
>> $r = $f + $d; // returns float result by default
>> $r = as_decimal($f + $d); // returns decimal result with a warning about
>> implicit float to decimal conversion
>>
>> All builtin functions that currently accept float also accept decimal. So
>> users don't need to care about separate function sets, and PHP
Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
On Thu, Dec 7, 2023 at 11:27 PM Jordan LeDoux wrote: You are going to run into some very difficult corners on this one. For the > last... 8 years i guess? I have been working on an arbitrary precision > library for PHP in userland. It utilizes BCMath, ext-decimal, and GMP, > depending on what is installed and what kind of operation you are > performing. > > So, the functions that currently accept floats include functions such as > `sin()` or `atan()`. These functions are not at all trivial to do to > arbitrary precision. In fact, the VAST majority of the work I have done on > my library has been to handle cases like "What do I do if the user wants > 2.921 ** 4.293810472934854?" or "How will I guarantee the precision that > the user requested for `tan()` in an efficient way?" > > Now, libmpdec is going to actually have implementations for most of this > stuff that you can call directly, but if the PHP function `sin()` isn't > capable of *outputting* a `decimal`, then this isn't really that much of an > improvement over the current situation. I mean, it's still something I > would support, but that's the area where some help from the engine goes a > VERY long way. > In my proposal, builtin functions are capable of returning decimals if they're fed with decimals. You're probably also going to need a way for a user to grab certain > constants to a given precision. I would think e and pi at the least. > > I have a lot of experience working on this problem space in PHP, and am > definitely willing to help. I looked into doing a libmpdec PHP integration > several years ago, but decided that voters were unlikely to give it a fair > shot, and so decided against it. If you're willing to try and roll the ball > up the hill though, I'll definitely help you. > Unfortunately, I'm not an expert in precise math. I definitely need help from experts like you. I appreciate your readiness. I understand that there are a lot of edge cases. I would propose to implement basics at first and then decide what to do with edge cases.
Re: [PHP-DEV] Filesystem path APIs
Hi Niels,
On Wed, 6 Dec 2023 at 19:20, Niels Dossche wrote:
> Hi internals
>
> I'd like to start a pre-RFC discussion about filesystem path APIs in PHP.
> The reason I bring this up is because of this recent feature request:
> https://github.com/php/php-src/issues/11258
>
> The feature request is about the following:
> We already have some functions to work with paths in PHP, e.g. basename,
> dirname, realpath.
> We do not have some common path APIs that you can find in other languages
> like: path_join to join paths and path_normalize to normalize paths.
>
> As not everyone may be familiar with such functions, I'll explain them
> briefly.
>
> **Proposed Functions:**
>
> 1. path_join(string... $components): string;
> This function concatenates the components with a / (or \ on Windows)
> between them and normalizes the path.
> If the resulting path is empty then it'll return "." to indicate the
> current directory.
> You may be wondering "Isn't this just implode?". Not really, it normalizes
> the path too, which means that components like "." are removed from the
> path, redundant slashes are removed, and if there are ".." components then
> they remove the previous component from the path.
>
> It's also not the same thing as calling realpath after doing implode:
> realpath would not work for non-existent paths and it would allow escaping
> from the root.
> To demo the root escape problem:
> path_join("..", "foo"); yields "foo"
> Whereas realpath("../foo"); yields the absolute path of the "foo" file one
> directory up.
>
> Note: This function does not do any I/O.
>
> 2. path_normalize(string $path): string;
>
> This function only does the normalization part described above.
> Note: This function also does not do any I/O.
>
> **Examples:**
>
> ```php
> // Example usage of path_join
> $result = path_join('dir1', 'dir2', '..', 'file.txt'); // Resolves to
> 'dir1/file.txt'
>
> // Example usage of path_normalize
> $normalizedPath = path_normalize('dir1/../dir2'); // Resolves to 'dir2'
> ```
>
>
> I think these would be great additions to PHP as working with paths and
> files is a core part of any programming language.
>
>
> Seems like it, is there an argument to be made to, let's say, in the
performance side ?
Re: [PHP-DEV] Filesystem path APIs
On Fri, Dec 8, 2023 at 11:45 AM Lanre Waju wrote: > So your suggestion for simple file stuff is to download composer? > Not necessarily, but I'd like to have more discussion of pros and cons. -- Best regards, Max Semenik
Re: [PHP-DEV] Filesystem path APIs
So your suggestion for simple file stuff is to download composer? On 2023-12-08 1:43 a.m., Max Semenik wrote: On Wed, Dec 6, 2023 at 10:20 PM Niels Dossche wrote: Hi internals I'd like to start a pre-RFC discussion about filesystem path APIs in PHP. The reason I bring this up is because of this recent feature request: https://github.com/php/php-src/issues/11258 The feature request is about the following: We already have some functions to work with paths in PHP, e.g. basename, dirname, realpath. We do not have some common path APIs that you can find in other languages like: path_join to join paths and path_normalize to normalize paths. We have a lot of commonly used functionality that's successfully fulfilled by Composer packages - does this really have to be core functionality? I understand the argument about batteries included, but across mainstream languages you can always find examples of something that sounds like it should really be there, but it isn't. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Filesystem path APIs
On Wed, Dec 6, 2023 at 10:20 PM Niels Dossche wrote: > Hi internals > > I'd like to start a pre-RFC discussion about filesystem path APIs in PHP. > The reason I bring this up is because of this recent feature request: > https://github.com/php/php-src/issues/11258 > > The feature request is about the following: > We already have some functions to work with paths in PHP, e.g. basename, > dirname, realpath. > We do not have some common path APIs that you can find in other languages > like: path_join to join paths and path_normalize to normalize paths. > We have a lot of commonly used functionality that's successfully fulfilled by Composer packages - does this really have to be core functionality? I understand the argument about batteries included, but across mainstream languages you can always find examples of something that sounds like it should really be there, but it isn't. -- Best regards, Max Semenik
