Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
On Wed, 13 Dec 2023 at 09:29, Alexander Pravdin
wrote:
> On Wed, Dec 13, 2023 at 6:11 PM Robert Landers
> wrote:
>
> I just ran `apt install php8.3-decimal` and tried this:
> >
> > $a = new Decimal\Decimal("1", 2);
> > $b = $a + $a;
> > PHP Warning: Uncaught TypeError: Unsupported operand types:
> > Decimal\Decimal + Decimal\Decimal in
> >
> > So, it appears not.
> >
>
> I've pointed out this issue earlier in the discussion and Gina P. Banyard
> has replied that this can be a PHP 8.3 bug and he will look into it.
>
> BTW, my main concern is that this amazing extension doesn't look like it is
> actively maintained and I'm worrying if I will be able to maintain my
> projects that depend on it in the future.
>
Hot take, why not fund the maintainer (or someone else to fork and pick up
the work) to work on this extension?
It is not like most bundled extension within php-src are truly actively
maintained.
So why would integrating ext/decimal mean it will be maintained?
Just have a look at all the XML/DOM related extensions that were riddled
with bugs and unmaintained until Nils decided to pick up the work to
scratch an itch.
Moreover, being separate from "core" is frankly a benefit, and I very much
dislike the current status of having so many bundled extensions that cannot
improve at their own pace.
Having extensions not be tied to php-src's release cycle means they can
move more quickly, fix bugs faster, evolve more easily, etc.
Just look at ext/curl, being stuck at a certain level of support for
libcurl because it *must* be tied to the annual PHP release cycle.
Best regards,
Gina P. Banyard
PS: My pronouns are she/her
Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
On Tue, 12 Dec 2023 at 21:00, Robert Landers wrote: > On Tue, Dec 12, 2023 at 2:04 PM G. P. B. wrote: > > GMP supports operator overloading > > GMP kinda-sorta-most-of-the-time supports operator overloading. > Sometimes ... it doesn't. I implemented a field library in PHP (for > work a couple of years ago) and occasionally, overloading would cast > things back to float/int and break the math. I don't have access to > that code, so I don't have any examples readily available (and the > fact that an extension can do overloading but we can't in user-land is > a whole different can of worms which made this library ridiculously > hard to work with -- we rewrote everything in Scala and never looked > back). Needless to say, if I were to go into a project that required > GMP, I wouldn't trust the overloading. > I have no idea how _this_ is possible considering GMP will happily throw type errors left and right even in cases when it shouldn't. If you encountered this, you should have submitted a bug report. Because, using a potential bug as an excuse for not doing this is... weird? I have come around userland operator overloading with the proposal from Jordan, but considering this hasn't passed it might take a while before someone gives it a crack at it again. And it has _always_ been a thing that the engine, and internal extensions, can do more things than userland. Especially nonsensical stuff like variadic parameters not at the end... Gina P. Banyard
Re: [PHP-DEV] Are warnings guaranteed?
Hi On 14/12/2023 11:39, petrov.boris.v.mail.ru via internals wrote: > Is relying on warnings being converted to exceptions by error handler is > equivalent to checking return value with regards to the set of error > conditions covered? If this guarantee is already there, please point to me to > the relevant documentation page. > No. AFAIK there is no such formal requirement. Concrete example: at least ftp_connect doesn't: https://github.com/php/php-src/issues/9898. Also I know of some methods in ext/dom that can return false without emitting a warning. Kind regards Niels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Are warnings guaranteed?
Hey Boris, On Thu, 14 Dec 2023 at 11:39, petrov.boris.v.mail.ru via internals < internals@lists.php.net> wrote: > The above code confuses a reader with issues 1) isn't the only possible > return value is now true? 2) if it throws on failure, then how can it > return anything? > Just worth mentioning that https://github.com/thecodingmachine/safe/tree/3a6e43b4be3d3d65b272c2660300a50658ce168b maps out all warning-emitting PHP functions to usable variants :-) There's also a PHPStan integration to prevent people from shooting themselves in the foot while using the php-src provided legacy functions (which will likely keep emitting warnings for a while, due to BC concerns). Marco Pivetta https://mastodon.social/@ocramius https://ocramius.github.io/
[PHP-DEV] Are warnings guaranteed?
Hi. I have a question: Is there a formal rule in PHP standard library
that any function which returns false as a mean to signify a failure
does also issue a warning?
In many codebases warnings are converted to an exception by means of
set_error_handler().
Example 1
--
set_error_handler(fn($_, $s) => throw new \RuntimeException($s));
if (false === mkdir('/doesn/t/exist/dir')) {
throw new \RuntimeException("can't mkdir");
}
--
The above code confuses a reader with issues 1) isn't the only possible
return value is now true? 2) if it throws on failure, then how can it
return anything?
One may say the checking for false return value is redundant and the
above version can be simplified based on premise that mkdir() emits
warning in _all_ cases where it is about to return false.
Example 2
--
set_error_handler(fn($_, $s) => throw new \RuntimeException($s));
mkdir('/doesn/t/exist/dir');
--
But there is also a possibility that a built-in function fails, returns
false but doesn't issue any warning, therefore the handler set with
set_error_handler() doesn't get called and execution continues
erroneously contrary to the programmer intend of it being halted.
Looking at mkdir() documentation I can't find the language supporting
assumption made in Example 2.
The page lists two cases for which warnings are raised: "directory
already exists" and "relevant permissions prevent creating the directory".
Does it mean that in case of "No such file or directory" the function
would return false without raising a warning? It is possible as
documentation never stated mkdir() would emit warning on _any_ failure,
just return false.
One may add a unit-test against mkdir() to the one's project codebase
proving that "Warning: mkdir(): No such file or directory" is raised
too, despite not being listed in documentation. So far we have three
cases covered. But obviously this doesn't prove that a warning would be
raised for all failures, thus doesn't allow us to deem Example 2 correct
and replace Example 1 with it.
Is relying on warnings being converted to exceptions by error handler is
equivalent to checking return value with regards to the set of error
conditions covered? If this guarantee is already there, please point to
me to the relevant documentation page.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
