Re: [PHP-DEV] [RFC] [Discussion] Change the edge case of round()
Hi Claude, > Reading the RFC, it is unclear for me what are the benefits of the change, > and whether it is worth the subtle breaking of existing code that implicitly > relies on the current behaviour. “FP is just FP” looks like an ideal > position, and one that has a counteragument given in the RFC that introduced > the current behaviour. > > We could live with any behaviour of round(), and they are arguments on both > sides. My issue at this point is not exactly what behaviour we have picked, > but whether changing between the two is sufficiently motivated. As for the motivation for the change, it's based on the idea that the current `round()` behavior is some kind of bug. In other words, the behavior of HALF_UP `0.285` to become `0.29` is itself a bug. To be honest, I'm completely neutral on this. I believe that this is a matter of will and what we want to do. As far as I know, Tim and Gina want change on this issue. I don't want to ignore such opinions and move forward with implementation, so I would like to hear a wider range of opinions. I have created this RFC in order to determine "our intention" once again. Regards. Saki
Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX
Hi Hans, > I think it'd be a good idea if they used FILTER_VALIDATE_BOOLEAN and > FILTER_VALIDATE_INTEGER type logic, with an error if conversion fails.. This can be difficult. Forcing an error is highly likely to destroy the existing user environment. > I wonder if PDO::PARAM_BOOL_OR_NULL would be worthwhile That's what I thought at first, but I think it might be a good idea to leave it as a fallback, especially for NULL. In fact, there have been proposals to deprecate PARAM_NULL in the past, but none have made it to the voting phase. I have not looked into it in detail yet, but I suspect that during the discussion stage, they may have come to the conclusion that it should not be abolished. Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX
Hi,
I think this is probably the same problem that Matteo ran into, but when using
emulate mode, pgsql errors out with code like this:
```
true,
],
);
$db->exec('CREATE TABLE test2 (val BOOLEAN)');
$stmt = $db->prepare('INSERT INTO test2 VALUES(:val)');
$stmt->bindValue(':val', 1, PDO::PARAM_INT);
$stmt->execute();
```
```
Fatal error: Uncaught PDOException: SQLSTATE[42804]: Datatype mismatch: 7
ERROR: column "val" is of type boolean but expression is of type integer
```
It seems a little strange that whether an error occurs or not depends on
whether you are in emulation mode or not.
Saki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX
As Ayesh says, I'm starting to feel like I need to provide a completely new feature separately tbh… The following issues are completely bugs and should at least be fixed. https://github.com/php/php-src/issues/12581 Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Discussion] Variable Type Declaration Before Usage
On Mon, Nov 6, 2023 at 3:08 AM David Gebler wrote:
>
> On Sun, Nov 5, 2023 at 1:37 PM Oladoyinbo Vincent
> wrote:
>
> > Hello Internals,
> >
> > I was wondering if php could introduce this feature or if any experienced C
> > dev here can work on the implementation of this feature.
> >
> >
> I think this is a much bigger issue than bikeshedding over syntax. The idea
> of typed variables has been discussed a few times in recent years but the
> roadblocks have been efficiency of any possible implementation, BC in
> respect of places type hinting can already be used and the overall
> usefulness / desirability of the feature. It's one of those things that's
> been filled in reasonably well by third party static analysis tools. Tbh
> I'd be more interested in an official static analyzer than more type checks
> at runtime.
It's also worth adding that many times, certain functions cannot be
chained elegantly or the nesting level gets out of hand, making
reusing variables a way to handle that:
$name = implode(' ', array_map(ucfirst(...), $name));
might be more readable to write as:
$name = array_map(ucfirst(...), $name);
$name = implode(' ', $name);
In this case, $name turns from an array to a string. Having to come up
with unique enough variable names just to satisfy type-checking would
be rather annoying (and it is in other languages).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Discussion] Variable Type Declaration Before Usage
Local based variable declaration before usage is available in most languages like javascript, python, and many more. php has this, but it's only available while working/dealing with oop related. Hello Oladoyinbo, I'll contribute an observation, correct me if I'm wrong. In Python or Javascript it is not possible to declare types, as they are dynamic languages, similar to PHP. What you can do in Python is write type annotations, but it doesn't change its type at run time. ```python myVar: int = 5; print(myVar); # The output is 5 myVar = 'Marcos'; print(myVar); # The way out is Marcos myVar = True; print(myVar); # The output is True ``` As for Javascript, it doesn't even have type annotations, you need to use `JSDoc` to document, or use `Typescript` to use types. Hug. --- Marcos Marcolin Software Engineer | PHP www.marcosmarcolin.com.br
