Re: [PHP-DEV] RFC Proposal - Types for Inline Variables
From: Olle Härstedt
Sent: Tuesday, February 7, 2023 11:53 AM
To: Rowan Tommins
Cc: PHP Internals
Subject: Re: [PHP-DEV] RFC Proposal - Types for Inline Variables
2023-02-07 17:21 GMT+01:00, Rowan Tommins :
> On 07/02/2023 14:07, Olle Härstedt wrote:
>> It should perhaps be mentioned that analyzers can use type annotations
>> during their process, instead of the more clunky /** @var string */ or
>> similar you have to use today for local variables.
>
> This sounds like you're reaching for Python's approach, where the
> language "supports" the type annotation syntax, but doesn't actually do
> anything with it.
No not really. I'd expect it behave similar to function argument
type-hinting in PHP, that is, runtime checks, but where the notation
can be used by external tools.
Olle
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Hi,
Wanted to add my two cents on potential usefulness of typed variables.
I think, typed variables would be a necessary prerequisite for typed arrays and
eventually generics.
If my understanding is correct, the primary concern there is performance
overhead of iterating items for type checking.
With typed variables, type checking is done at assignment and passing typed
array around becomes lightweight.
It would be enough to type check against a known array item type without
iterating over items.
For example:
function do_something(array $strings) {
...
}
array $names = ['John', 'Jane', 'Jake']; // items are type checked
similar to variadic argument unpacking
sort($names);
do_something($names); // lightweight type check as for scalar types
(I'm a recent mailing list subscriber and have no RFC voting rights whatsoever).
+1 to the proposal as it would nicely complete the type system of PHP.
It's pretty odd to have typed arguments and properties, but not variables.
Moving one step closer to retiring PHPDocs for good is very good as well.
Re: [PHP-DEV] RFC Proposal - Types for Inline Variables
On 07/02/2023 20:53, Olle Härstedt wrote: No not really. I'd expect it behave similar to function argument type-hinting in PHP, that is, runtime checks, but where the notation can be used by external tools. The big difference is that the current checking for function arguments is only necessary when a function is called; but that checking for local-scoped variables would be required on every assignment to a variable, or operation that can change a variable value; and that becomes more problematic with the potential need for union types. $mystring = 'I love elephants'; $findme = 'php'; int $pos = strpos($mystring, $findme); // $pos can be an integer or false or when a type can legitimately change int $result = PHP_MAX_INT; ++$i; // $i is now a float -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal - Types for Inline Variables
2023-02-07 17:21 GMT+01:00, Rowan Tommins : > On 07/02/2023 14:07, Olle Härstedt wrote: >> It should perhaps be mentioned that analyzers can use type annotations >> during their process, instead of the more clunky /** @var string */ or >> similar you have to use today for local variables. > > This sounds like you're reaching for Python's approach, where the > language "supports" the type annotation syntax, but doesn't actually do > anything with it. No not really. I'd expect it behave similar to function argument type-hinting in PHP, that is, runtime checks, but where the notation can be used by external tools. Olle -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal - Types for Inline Variables
On 07/02/2023 14:07, Olle Härstedt wrote: It should perhaps be mentioned that analyzers can use type annotations during their process, instead of the more clunky /** @var string */ or similar you have to use today for local variables. This sounds like you're reaching for Python's approach, where the language "supports" the type annotation syntax, but doesn't actually do anything with it. I explained in another thread why I think that is a poor compromise, because it's unclear whether you can actually trust the annotations. The current "clunky" syntax is clearly a comment as far as the language itself is concerned, so there is no expectation when reading it that it will have a meaning to plain PHP. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate ldap_connect with host and port as separate arguments
On Tue, 7 Feb 2023 at 12:56, Côme Chilliet wrote: > Le vendredi 27 janvier 2023, 10:00:35 CET Andreas Heigl a écrit : > > Hey Folks. > > > > I think it would be a good idea to deprecate calling ldap_connect with 2 > > parameters host and port. > > Hello, > > My long term plan was to replace it by a constructor for the new > \LDAP\Connection class that only accepts the URI syntax. Which would also > be better because ldap_connect is a really confusing name as it does not > actually connect to anything. > > But I’m unfamiliar with how to write object methods into PHP modules, and > I do not have much time to allocate to php-ldap. > > If you are interested into working on some OO methods for php-ldap > classes, I have a ton of ideas on how to make it awesome. > > Côme > Please let me know and I can spend some time on it. I also think working with objects was made significantly easier now that we have proper stubs and derive a lot of code generation from it. Best regards, George P. Banyard
Re: [PHP-DEV] Deprecate ldap_connect with host and port as separate arguments
Le vendredi 27 janvier 2023, 10:00:35 CET Andreas Heigl a écrit : > Hey Folks. > > I think it would be a good idea to deprecate calling ldap_connect with 2 > parameters host and port. Hello, My long term plan was to replace it by a constructor for the new \LDAP\Connection class that only accepts the URI syntax. Which would also be better because ldap_connect is a really confusing name as it does not actually connect to anything. But I’m unfamiliar with how to write object methods into PHP modules, and I do not have much time to allocate to php-ldap. If you are interested into working on some OO methods for php-ldap classes, I have a ton of ideas on how to make it awesome. Côme -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal - Types for Inline Variables
On 06/02/2023 21:15, someniatko wrote: Can you describe some use cases where this feature will be useful? I see it's coming from statically typed / compiled languages like C++, but in such languages compiler must know variable type in order to manage memory properly. As PHP is an interpreted language, it doesn't have this problem. I'm not convinced the distinction between "compiled" and "interpreted" languages is actually meaningful for modern language implementations - PHP does have a compilation step, and even performs some of its correctness checks at that stage. Much more important is the distinction between "static typing" and "dynamic typing". The aim of a static typing system is to *prove*, in the mathematical sense, that the program is correct according to the type system of the language, without executing any of the code. The aim of a "dynamic typing" system is instead to *detect* problems in a program, while it is running, and to select operations overloaded based on the actual type of data. PHP itself currently only includes dynamic typing features - effectively, all the type keywords you add to the source code translate to run-time assertions that check the type of data at specific points. Mostly, that's currently at function boundaries (parameter and return type checking), though typed properties are more complex (especially when you access one by reference, and get a "typed reference"). One of the big implications of that is performance: adding checks in more places (e.g. on every assignment to a local variable), or more complex checks (e.g. checking every element of an array), means that the actual program runs slower. It may be possible to implement checks in a more efficient way, but it's not going to be a simple patch. That's why including an official static analyser is tempting, but it's not obvious where that would fit in the project and ecosystem (see the recent thread on that topic). Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal - Types for Inline Variables
Hey, thanks for the feedback Illia and Hans.
Illia, I think that the main motivation for having the support of typing inline
variables is that with that we can have more safety in the code.
The code can be more shielded from bugs and easier to maintain.
I don't dislike the idea of having something like const on JS, but I think that
adding the support to add types to inline variables at least IMO is a step
further on all the typing that was already added in the language.
We have today the ability to add types to function arguments, return and in
class properties. So this is just another step towards adding support to
optional typing on another place.
Types can bring more confidence when writing code, you can see that for example
a lot of people in the JS community is now using TypeScript because of the
types.
I love that PHP already added type support to a lot of places and adding the
support for typing inline variables would be a game changer for the language I
think.
Hans, you sent a good example.
I think that in this case, it should throw a TypeError, yes.
I know this would add a lot of breaking changes.
But if we want to avoid some breaking changes we for example make use of the
declare(strict_types=1) to enforce this if this would means in less breaking
changes.
---
Best Regards,
Wendell Adriel.
Software Engineer | Investor | Amateur Photographer | Musician | INFP
https://wendelladriel.com
On Tue, 07 Feb 2023 08:34:07 + Hans Henrik Bergan
wrote ---
function f(int $value){
$value="foo"; // should this be a TypeError? BC break all the things
}
On Mon, 6 Feb 2023 at 22:15, someniatko wrote:
>
> Hi there,
>
> I am not a core PHP language developer, just a regular PHP programmer, and
> cannot speak for the whole community, so I'll just share my opinion.
>
> I believe a new language feature suggestion should contain not only its
> description, but also motivation: i.e. what are we trying to achieve with
> it. Will the development experience be worse without it, or maybe it
> disallows some sneaky bugs to appear in your code, or maybe it acts as a
> native documentation for your code etc.
>
> Personally it's hard for me to see what kind of improvement will
> restricting a type of a variable bring. It may prevent repurposing the
> variable with the same name for a different use somewhere down the
> function, which can lead to bugs if a function is large enough. However,
> for such cases I think better idea would be to introduce `const` variables
> like in JavaScript - which can only be set once and cannot be reassigned
> later. This way you'll also guarantee the type of the variable will be
> preserved.
>
> > We can add types in a lot of places, but we still don't have a way to add
> types to inline variables.
>
> > int $value = 10;
> > $value = 'foo'; // TypeError
>
> Can you describe some use cases where this feature will be useful? I see
> it's coming from statically typed / compiled languages like C++, but in
> such languages compiler must know variable type in order to manage memory
> properly. As PHP is an interpreted language, it doesn't have this problem.
>
> Regards,
> Illia / someniatko
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Vote] Readonly amendments
Hi Everyone, The vote for the "Readonly amendments" RFC is closed with the following results: Proposal #1 (Non-readonly classes can extend readonly classes): The proposal was declined with 7 yes and 12 no votes (37%). Proposal #2 (Readonly properties can be reinitialized during cloning): The proposal was accepted with 26 yes and 0 no votes (100%). Thanks to everyone who participated in the discussion or in the vote. Regards, Máté Kocsis
Re: [PHP-DEV] RFC Proposal - Types for Inline Variables
function f(int $value){
$value="foo"; // should this be a TypeError? BC break all the things
}
On Mon, 6 Feb 2023 at 22:15, someniatko wrote:
>
> Hi there,
>
> I am not a core PHP language developer, just a regular PHP programmer, and
> cannot speak for the whole community, so I'll just share my opinion.
>
> I believe a new language feature suggestion should contain not only its
> description, but also motivation: i.e. what are we trying to achieve with
> it. Will the development experience be worse without it, or maybe it
> disallows some sneaky bugs to appear in your code, or maybe it acts as a
> native documentation for your code etc.
>
> Personally it's hard for me to see what kind of improvement will
> restricting a type of a variable bring. It may prevent repurposing the
> variable with the same name for a different use somewhere down the
> function, which can lead to bugs if a function is large enough. However,
> for such cases I think better idea would be to introduce `const` variables
> like in JavaScript - which can only be set once and cannot be reassigned
> later. This way you'll also guarantee the type of the variable will be
> preserved.
>
> > We can add types in a lot of places, but we still don't have a way to add
> types to inline variables.
>
> > int $value = 10;
> > $value = 'foo'; // TypeError
>
> Can you describe some use cases where this feature will be useful? I see
> it's coming from statically typed / compiled languages like C++, but in
> such languages compiler must know variable type in order to manage memory
> properly. As PHP is an interpreted language, it doesn't have this problem.
>
> Regards,
> Illia / someniatko
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
