Re: [PHP-DEV] Type casting syntax

[Lynn]

On Mon, Jul 12, 2021 at 10:36 PM Mike Schinkel  wrote:

>
> In your hypothetical view here, what happens when the $container does not
> have SomeService to provide?  Does it throw an Exception?
>
>
Up to the developer that implements it. If the signature would be
`get(?string $id): T;` then I would assume an error should be thrown by
PHP, or an Exception by the method, or handled by the developer to always
return `T`. `?SomeException` as `T` could let the developer not throw an
exception if needed and return `null` instead.

Re: [PHP-DEV] Type casting syntax

[Max Semenik]

On Mon, Jul 12, 2021 at 11:20 PM Mike Schinkel  wrote:

> It seems you have just illustrated why in reality we really do not need
> type casting/assertions in PHP given its current features, because we
> already have what we need.
>

Heh, nope - you asked for handling of such cases without exceptions, I
obliged. My plans were around different usage scenarios. In any case, I'm
not making a proposal at this point, I'm just enquiring about syntax. If I
ever get something proposable done, I'll make a formal RFC.

-- 
Best regards,
Max Semenik

Re: [PHP-DEV] Type casting syntax

[Mike Schinkel]

> On Jul 12, 2021, at 4:28 PM, Lynn  wrote:
> On Mon, Jul 12, 2021 at 10:20 PM Mike Schinkel  > wrote:
> It seems you have just illustrated why in reality we really do not need type 
> casting/assertions in PHP given its current features, because we already have 
> what we need.
> 
> That's not an argument I agree with, as it would invalidate the need for 
> short closures, null coalesce, constructor property promotion, etc. 
> 
> Continuing on the previous example:
> ```php
> $service = $container->get(SomeService::class);
> assert($service instanceof SomeService);
> 
> // could be replaced with
> $container->get();

In your hypothetical view here, what happens when the $container does not have 
SomeService to provide?  Does it throw an Exception?

-Mike

Re: [PHP-DEV] Type casting syntax

[Lynn]

On Mon, Jul 12, 2021 at 10:20 PM Mike Schinkel  wrote:

> It seems you have just illustrated why in reality we really do not need
> type casting/assertions in PHP given its current features, because we
> already have what we need.
>

That's not an argument I agree with, as it would invalidate the need for
short closures, null coalesce, constructor property promotion, etc.

Continuing on the previous example:
```php
$service = $container->get(SomeService::class);
assert($service instanceof SomeService);

// could be replaced with
$container->get();

// or in case of multiple instances:
$container->get('the.service.alias');

// perhaps the service is optional
$container->get();
```

Re: [PHP-DEV] Type casting syntax

[Mike Schinkel]

> On Jul 12, 2021, at 1:56 PM, Max Semenik  wrote:
> 
> On Mon, Jul 12, 2021 at 8:01 PM Mike Schinkel  > wrote:
> Additionally in Go a type assertion can return a second value which is 
> boolean telling if the type assertion succeeded.  Not having this would 
> effectively moot the benefit to a type assertion if you had to wrap with 
> try{}catch{} in case it failed.
> 
> Not necessarily:
> 
> if ($obj instanceof MyClass) {
> // We know its type here
> } else {
>// Try something else
> }

Well there you go.  

It seems you have just illustrated why in reality we really do not need type 
casting/assertions in PHP given its current features, because we already have 
what we need.

-Mike

Re: [PHP-DEV] [RFC] [VOTE] is_literal

[Craig Francis]

On Mon, 12 Jul 2021 at 14:17, Dan Ackroyd  wrote:

> On Mon, 12 Jul 2021 at 02:09, Craig Francis 
> wrote:
> >
> > you can choose not to use string concatenation ... allowing anyone to
> customise it to their needs
>
> Please can you explain how:
>
> i) An individual programmer can enforce that they don't accidentally
> use string concatenation for stuff that is used in a security
> sensitive context.
>


i) Usually if developers want to add specific restrictions for themselves
or their team that the vast majority of a userbase would not need or use,
they would use a separate tool that fills that niche to enforce their
chosen coding style (like how they might want to enforce "tabs vs spaces"
in their own codebase).



> ii) A team of 50 programmers can enforce that they don't accidentally
> use string concatenation for stuff that is used in a security
> sensitive context.
>


ii) Same answer as i) as it scales.


iii) A library can enforce that string concatenation isn't used in the
> params passed to it.
>


iii) A library shouldn't care if the developer used concatenation, it
should only care if user data has been included incorrectly (i.e. checking
for an Injection Vulnerability). A library’s purpose is to ensure whether
code is safe or not, not about enforcing personal coding styles.


> and doesn’t improve security in any way,
>
> It [disallowing concatenation] prevents issues from being able to make it
> through to production.
> But the main reason would be to reduce the cost of using this feature
> long-term.
>


Disallowing concatenation doesn’t guarantee that issues can’t get through
to production though; for example, something that can sometimes be a
non-literal, but during development defaults to a literal.

>From a security point of view, it doesn’t matter whether the error is
caught at the point of concatenation, or when it’s checked as the library
receives it, because the injection vulnerability gets caught either way.

I take it the "cost" that you’re referring to is just the debugging time?
Ultimately any extra debug time that might occur, is magnitudes less than
the time it would take almost every developer to check and rewrite most of
the projects that exist today, which is what the idea of not supporting
concatenation requires.

For a developer who really finds debugging too onerous, there are other
ways of debugging - using tools better suited for it such as XDebug or
Static Analysis tools like Psalm (and as above, if you were wanting to
force yourself/your team to not concatenate, you would be using a Static
Analysis tool already (i/ii)).


> you can choose not to use string concatenation (I haven't needed to).
>
> Waitwhat?
>
> Is your position both that preserving literal-ness across string
> concatenation is required, otherwise this feature is too hard to use,
> and at the same time, you've not needed that in your own applications.
>
> Is that right? Because if preserving literal-ness across strings
> wasn't required for you...why would it be required for every other
> project?
>
> And to be clear, I don't think it's required.
>


We are trying to improve the language for the majority of developers.

I’m an experienced PHP developer who is genuinely passionate about
security. I find it fun, curating my code to be as secure as possible is
practically a hobby. That makes me an Outlier. Like a lot of us here. My
focus is on writing an RFC that works for as many developers as possible,
so whether it’s ‘necessary’ in my own personal projects is irrelevant to
whether a simple safety feature should exist for the community.

We need to make things easy and safe for the people who are /not/ just
high-level programmers, but for people who don’t know everything we do and
need things to be simple and functional as possible.

My projects do use a lot of string concatenation. Not an erroneously high
amount, probably about normal. So let’s say we do break string
concatenation: For some numbers, I've found roughly 1,300 instances of SQL
and HTML concatenation in my projects. And even if I would be willing to go
through such a big task to replace them, the real problem is actually
finding them, because if you’re trying to use a search, well, who would
have thought looking for "." would return so many results?



> I think by listening to feedback from people who aren't sure it's a
> good idea, who said "this is a good idea but only if it's really easy
> to start using it" that this RFC has been watered down from the most
> useful proposal. At the core, there is a good idea behind this RFC,
> but the set of trade-offs chosen just aren't the right ones, and
> aren't the "proven" trade-offs made at Google.
>


The proposal hasn’t changed. This is keeping to the original concept, and
while you wanted to remove string concatenation support, that does not mean
that anything so strict was our intention. The proposal was always meant
for the greatest and easiest adoption possible, but that was your 

Re: [PHP-DEV] Type casting syntax

[Max Semenik]

On Mon, Jul 12, 2021 at 8:01 PM Mike Schinkel  wrote:

> Additionally in Go a type assertion can return a second value which is
> boolean telling if the type assertion succeeded.  Not having this would
> effectively moot the benefit to a type assertion if you had to wrap with
> try{}catch{} in case it failed.
>

Not necessarily:

if ($obj instanceof MyClass) {
// We know its type here
} else {
   // Try something else
}

-- 
Best regards,
Max Semenik

Re: [PHP-DEV] Type casting syntax

[Mike Schinkel]

> On Jul 12, 2021, at 11:00 AM, Larry Garfield  wrote:
> x
> On Mon, Jul 12, 2021, at 9:54 AM, Max Semenik wrote:
> 
>> I was thinking of something akin to many compiled languages' approach of
>> "consider this expression is now of that type, and throw an exception if
>> it's not". An example of this approach from Benjamin's proposal of old^
>> 
>> $service = (EmailService) $diContainer->get('email.service');
>> 
>> Instead of
>> 
>> /** @var EmailService $service */
>> $service = $diContainer->get('email.service');
>> if (!$service instanceof EmailService) {
>>throw new TypeError('Expected instance of EmailService, ...');
>> }
> 
> Hm, that's a different creature.  I... would be probably OK with something in 
> that direction, though I wouldn't work on it myself.  I think what you're 
> describing here is more of a type assertion.  "Assert that this variable is 
> of type X, otherwise bail."  So, some kind of non-disableable (or maybe 
> disableable?) shorthand for `assert($foo instanceof Bar)`.

Regarding prior art on type assertion, the syntax Go uses is `value.(type)` so 
using a similar approach in PHP might look like this (I'm spitballing by using 
the double colon as a sigil but it could anything that doesn't conflict with 
existing usage, whatever those options are):

$service = $diContainer->get('email.service')::(EmailService);


Additionally in Go a type assertion can return a second value which is boolean 
telling if the type assertion succeeded.  Not having this would effectively 
moot the benefit to a type assertion if you had to wrap with try{}catch{} in 
case it failed.

$service, $okay = $diContainer->get('email.service')::(EmailService);
if (!$ok) {
   echo 'Not an EmailService.';
}

#fwiw

-Mike

Re: [PHP-DEV] Re: open_basedir?

[Christoph M. Becker]

On 12.07.2021 at 15:54, Nikita Popov wrote:

> On Thu, Jul 8, 2021 at 11:34 PM Stanislav Malyshev 
> wrote:
>
>>> Apparently, there has been no resolution for this issue so far.  While I
>>> don't really care about the open_basdedir directive per se, I fully
>>> agree that we should not advertize it as security feature, and to
>>> clearly state this in the PHP manual, as well as in our security policy.
>>
>> Correct. As I mentioned, de-facto it's already the case for years now.
>> Let's fix the docs at least? Though I'd really start thinking about
>> maybe removing it in the next major version...
>
> Yeah, feel free to go ahead with updates for docs & security policy.

Done with

and .

Christoph

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Type casting syntax

[Larry Garfield]

On Mon, Jul 12, 2021, at 9:26 AM, Levi Morrison via internals wrote:

> > What are the use cases for integrated object to object (ie, class to class) 
> > conversion in PHP?  Rust's type system is a very different beast, so its 
> > casting logic makes more sense there.  I'm not entirely clear on what the 
> > use case is in PHP.  When would that be superior to "just write an asFoo() 
> > method and move on with life"?
> >
> > Scalar conversion I can see, but every time someone suggests adding 
> > siblings to __toString(), there's major pushback.
> >
> > --Larry Garfield
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> 
> The features I was referring to are not casting; casting does exist in
> Rust but this is not it. Rather, it's a generic way to convert
> objects. It's nice to have a standard way to do it, instead of every
> project doing something bespoke. It also can enable some use cases
> that aren't relevant in PHP (yet) such as taking any generic type
> which can be converted into a T, because you only want to do that
> transformation conditionally on something else.

So, like David suggested, some standardized version of $foo->as($type), which 
then returns an instance of $type?

I... don't think I've ever done that often enough to justify a standard feature 
for it.  When have you run into it?

That also seems quite different from what Max is talking about:

On Mon, Jul 12, 2021, at 9:54 AM, Max Semenik wrote:

> I was thinking of something akin to many compiled languages' approach of
> "consider this expression is now of that type, and throw an exception if
> it's not". An example of this approach from Benjamin's proposal of old^
> 
> $service = (EmailService) $diContainer->get('email.service');
> 
> Instead of
> 
> /** @var EmailService $service */
> $service = $diContainer->get('email.service');
> if (!$service instanceof EmailService) {
> throw new TypeError('Expected instance of EmailService, ...');
> }

Hm, that's a different creature.  I... would be probably OK with something in 
that direction, though I wouldn't work on it myself.  I think what you're 
describing here is more of a type assertion.  "Assert that this variable is of 
type X, otherwise bail."  So, some kind of non-disableable (or maybe 
disableable?) shorthand for `assert($foo instanceof Bar)`.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Type casting syntax

[Max Semenik]

I was planning to propose something closer to

On Mon, Jul 12, 2021 at 2:19 AM Larry Garfield 
wrote:

> What are the use cases for integrated object to object (ie, class to
> class) conversion in PHP?  Rust's type system is a very different beast, so
> its casting logic makes more sense there.  I'm not entirely clear on what
> the use case is in PHP.  When would that be superior to "just write an
> asFoo() method and move on with life"?
>
> Scalar conversion I can see, but every time someone suggests adding
> siblings to __toString(), there's major pushback.
>

I was thinking of something akin to many compiled languages' approach of
"consider this expression is now of that type, and throw an exception if
it's not". An example of this approach from Benjamin's proposal of old^

$service = (EmailService) $diContainer->get('email.service');

Instead of

/** @var EmailService $service */
$service = $diContainer->get('email.service');
if (!$service instanceof EmailService) {
throw new TypeError('Expected instance of EmailService, ...');
}

-- 
Best regards,
Max Semenik

Re: [PHP-DEV] [RFC] [VOTE] is_literal

[Rowan Tommins]

On 11/07/2021 18:00, Dan Ackroyd wrote:

What it won't do, is tell you when you've forgotten to use it,

Which is a huge difference.



You've edited out the crucial last part of that sentence:

> but nor would a built-in implementation


I don't know how to make this point more emphatically: Neither a 
built-in literal_concat function, nor setting the internal flag to false 
when you use the "." operator, can prevent you using plain concatenation 
in the wrong place.



Regardless of what the . operator does to the internal literal flag, the 
following code will give an error in exactly the same place:


// What this line does to the literal flag is irrelevant:
$blah = 'a' . 'b';
// This line will set the literal flag to false, but will not raise any 
errors:

$foo = $blah . $_GET['foo'];
// $foo is not literal, so $bar is not literal; but there are still no 
errors:

$bar = $foo . '123';
// Finally, an error will be raised when trying to use $bar in 
literal_concat, regardless of whether it's built-in or user-implemented:

$baz = literal_concat($bar, '456');


The only way to put that error in a different place would be if the . 
operator itself was able to raise errors, and I can't think of any way 
that would be possible.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Type casting syntax

[Levi Morrison via internals]

On Sun, Jul 11, 2021 at 5:19 PM Larry Garfield  wrote:
>
> On Sun, Jul 11, 2021, at 5:30 PM, Levi Morrison via internals wrote:
> > I like Rust's From and TryFrom traits, which allow types to define
> > conversions into or from other types. The From trait always succeeds,
> > and TryFrom can fail. However, it's not a "cast" -- the user calls an
> > `into`/`try_into` or `from`/`try_from` methods.
> >
> > I would be supportive of defining official ways to convert types from
> > one to another, not necessarily casts, though. I think these qualities
> > are important:
> >
> >  1. Would have failable and non-failable variants. It's nice to know
> > that a particular conversion cannot or can fail.
> >  2. It should be amenable to static analysis. Tools should be able to
> > warn about missing paths for handling failable conversions, or that
> > conversion from A to B is possible but A to C is not.
> >
> > I'm not sure how to technically achieve this for PHP. I don't think
> > any casting proposal I've seen meets these characteristics, so I would
> > personally vote no on them.
>
> What are the use cases for integrated object to object (ie, class to class) 
> conversion in PHP?  Rust's type system is a very different beast, so its 
> casting logic makes more sense there.  I'm not entirely clear on what the use 
> case is in PHP.  When would that be superior to "just write an asFoo() method 
> and move on with life"?
>
> Scalar conversion I can see, but every time someone suggests adding siblings 
> to __toString(), there's major pushback.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

The features I was referring to are not casting; casting does exist in
Rust but this is not it. Rather, it's a generic way to convert
objects. It's nice to have a standard way to do it, instead of every
project doing something bespoke. It also can enable some use cases
that aren't relevant in PHP (yet) such as taking any generic type
which can be converted into a T, because you only want to do that
transformation conditionally on something else.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: open_basedir?

[Nikita Popov]

On Thu, Jul 8, 2021 at 11:34 PM Stanislav Malyshev 
wrote:

> Hi!
>
> > Apparently, there has been no resolution for this issue so far.  While I
> > don't really care about the open_basdedir directive per se, I fully
> > agree that we should not advertize it as security feature, and to
> > clearly state this in the PHP manual, as well as in our security policy.
>
> Correct. As I mentioned, de-facto it's already the case for years now.
> Let's fix the docs at least? Though I'd really start thinking about
> maybe removing it in the next major version...
> --
> Stas Malyshev
> smalys...@gmail.com
>

Yeah, feel free to go ahead with updates for docs & security policy.

Regards,
Nikita

Re: [PHP-DEV] [RFC] [VOTE] is_literal

[Dan Ackroyd]

On Mon, 12 Jul 2021 at 02:09, Craig Francis  wrote:
>
> you can choose not to use string concatenation ... allowing anyone to 
> customise it to their needs

Please can you explain how:

i) An individual programmer can enforce that they don't accidentally
use string concatenation for stuff that is used in a security
sensitive context.

ii) A team of 50 programmers can enforce that they don't accidentally
use string concatenation for stuff that is used in a security
sensitive context.

iii) A library can enforce that string concatenation isn't used in the
params passed to it.


> and doesn’t improve security in any way,

It prevents issues from being able to make it through to production.
But the main reason would be to reduce the cost of using this feature
long-term.

> you can choose not to use string concatenation (I haven't needed to).

Waitwhat?

Is your position both that preserving literal-ness across string
concatenation is required, otherwise this feature is too hard to use,
and at the same time, you've not needed that in your own applications.

Is that right? Because if preserving literal-ness across strings
wasn't required for you...why would it be required for every other
project?

And to be clear, I don't think it's required.

I think by listening to feedback from people who aren't sure it's a
good idea, who said "this is a good idea but only if it's really easy
to start using it" that this RFC has been watered down from the most
useful proposal. At the core, there is a good idea behind this RFC,
but the set of trade-offs chosen just aren't the right ones, and
aren't the "proven" trade-offs made at Google.

cheers
Dan
Ack

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: Bundled Extension namespace(s)

[Pierre R.]

Le 12 juillet 2021 13:39:50 GMT+02:00, "Christoph M. Becker" 
 a écrit :
>On 12.07.2021 at 13:33, Pierre Joye wrote:
>
>> I would go with Gd, double uppercase is "harder" to type  :)
>
>+1.  That also matches GdImage and GdFont.
>
>Christoph
>
>-- 
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: https://www.php.net/unsub.php

Hello,

I am not fond of 2-letters namespace names, juste saying it for the sake of 
saying it. Does the policy cover that ?

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

[PHP-DEV] Re: Bundled Extension namespace(s)

[Christoph M. Becker]

On 12.07.2021 at 13:33, Pierre Joye wrote:

> I would go with Gd, double uppercase is "harder" to type  :)

+1.  That also matches GdImage and GdFont.

Christoph

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [External] : [PHP-DEV] Re: [VOTE] Deprecations for PHP 8.1

[Christopher Jones]

On 12/7/21 5:49 pm, Nikita Popov wrote:

On Wed, Jun 30, 2021 at 11:32 AM Nikita Popov  wrote:


Hi internals,

I have opened voting on 
https://urldefense.com/v3/__https://wiki.php.net/rfc/deprecations_php_8_1__;!!ACWV5N9M2RV99hQ!eOdPIFLsofVNrUBd4W7sbMWdcjqDAxoj6dUr1ubpwolU9F88ArjY_it8fiKBOoU67d5vLg$
 .
The vote closes on 2021-07-14.

This RFC is a collection of various deprecation suggestions from different
people. Each deprecation is voted separately, and should be considered on
its own merit.

Most deprecations should be uncontroversial, but there are some more
contentious ones as well: See 
https://urldefense.com/v3/__https://externals.io/message/113657__;!!ACWV5N9M2RV99hQ!eOdPIFLsofVNrUBd4W7sbMWdcjqDAxoj6dUr1ubpwolU9F88ArjY_it8fiKBOoXqarWpuA$
  for
additional discussion.


The oci8.old_oci_close_semantics deprecation is looking for someone to
implement it (I'm not sure who added it in the first place). I have
everything else covered, but don't have an oci8 test environment to work on
this one.

Regards,
Nikita


I will do it.

Chris

--
https://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: Bundled Extension namespace(s)

[Pierre Joye]

On Mon, Jul 12, 2021, 6:31 PM Christoph M. Becker  wrote:

> On 12.07.2021 at 11:10, Pierre Joye wrote:
>
> > What is the status of the extension namespace RFC
> > (https://wiki.php.net/rfc/namespaces_in_bundled_extensions)?
> >
> > In the near future, I plan to work a bit on the ext/gd one. Adding
> > quite a few things I have in my queue for too long. Check
> > https://github.com/libgd/libgd/issues/705 if interested.
> >
> > I am not sure about the base NS to be used. if I follow the RFC, it
> > should be Image\.
>
> The RFC states:
>
> | The top-level namespace should match the extension name (apart from
> | casing).
>

Ah I missed that part, I was looking at examples  :)


> So shouldn't the namespace rather be Gd or GD?
>

I would go with Gd, double uppercase is "harder" to type  :)

best,
Pierre

>

[PHP-DEV] Re: Bundled Extension namespace(s)

[Christoph M. Becker]

On 12.07.2021 at 11:10, Pierre Joye wrote:

> What is the status of the extension namespace RFC
> (https://wiki.php.net/rfc/namespaces_in_bundled_extensions)?
>
> In the near future, I plan to work a bit on the ext/gd one. Adding
> quite a few things I have in my queue for too long. Check
> https://github.com/libgd/libgd/issues/705 if interested.
>
> I am not sure about the base NS to be used. if I follow the RFC, it
> should be Image\.

The RFC states:

| The top-level namespace should match the extension name (apart from
| casing).

So shouldn't the namespace rather be Gd or GD?

Christoph

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Fake Closure Comparison

[Patrick ALLAERT]

Le lun. 12 juil. 2021 à 11:42, Patrick ALLAERT  a
écrit :

> Le lun. 12 juil. 2021 à 09:51, Nikita Popov  a
> écrit :
>
>> I'm also not sure where this would be actually useful (though I'm okay
>> with including it, as the functionality itself seems sensible). As Patrick
>> Allaert suggested this, maybe he can comment on some use cases.
>>
>
> I can't really see a useful case either, it was more rhetorical.
>

Maybe:

if ($f == unlink(...)) {
logging("Deleting $x");
}

$f($x);

Re: [PHP-DEV] Fake Closure Comparison

[Patrick ALLAERT]

Le lun. 12 juil. 2021 à 09:51, Nikita Popov  a écrit :

> I'm also not sure where this would be actually useful (though I'm okay
> with including it, as the functionality itself seems sensible). As Patrick
> Allaert suggested this, maybe he can comment on some use cases.
>

I can't really see a useful case either, it was more rhetorical.

For a feeling I can't explain much, I was caring less about:
Closure::fromCallable('strlen') == Closure::fromCallable('strlen')

than:
strlen(...) == strlen(...)

I know they are technically identical, but I see the first construct as a
function call while the second one looks more like a language construct
"referencing" (sorry for not using a more adequate verb) the same function.

Anyway, I don't have a strong opinion on it.

Regards,
Patrick

[PHP-DEV] Bundled Extension namespace(s)

[Pierre Joye]

Good afternoon internals,

What is the status of the extension namespace RFC
(https://wiki.php.net/rfc/namespaces_in_bundled_extensions)?

In the near future, I plan to work a bit on the ext/gd one. Adding
quite a few things I have in my queue for too long. Check
https://github.com/libgd/libgd/issues/705 if interested.

I am not sure about the base NS to be used. if I follow the RFC, it
should be Image\.

What do you think?

Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Fake Closure Comparison

[Nikita Popov]

On Fri, Jul 9, 2021 at 12:08 PM Pierre  wrote:

> Le 09/07/2021 à 10:45, Joe Watkins a écrit :
> > Morning internals,
> >
> > While discussing some of the details of the first class callable RFC, it
> > became apparent that fake closures (created by Closure::fromCallable) are
> > not currently comparable in a useful way.
> >
> > Although this is not directly related to the first class callable
> feature,
> > it's likely that the proliferation of this kind of code will follow, so
> now
> > seems like a good time to fix the problem.
> >
> > https://github.com/php/php-src/pull/7223
> >
> > Any objections to merging that in master ?
> >
> > Cheers
> > Joe
>
> I don't see where I would actually compare callables, and I'm not an
> engine maintainer, but from my point of view, this patch makes sense.
>

I'm also not sure where this would be actually useful (though I'm okay with
including it, as the functionality itself seems sensible). As Patrick
Allaert suggested this, maybe he can comment on some use cases.

Regards,
Nikita

[PHP-DEV] Re: [VOTE] Deprecations for PHP 8.1

[Nikita Popov]

On Wed, Jun 30, 2021 at 11:32 AM Nikita Popov  wrote:

> Hi internals,
>
> I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1.
> The vote closes on 2021-07-14.
>
> This RFC is a collection of various deprecation suggestions from different
> people. Each deprecation is voted separately, and should be considered on
> its own merit.
>
> Most deprecations should be uncontroversial, but there are some more
> contentious ones as well: See https://externals.io/message/113657 for
> additional discussion.
>

The oci8.old_oci_close_semantics deprecation is looking for someone to
implement it (I'm not sure who added it in the first place). I have
everything else covered, but don't have an oci8 test environment to work on
this one.

Regards,
Nikita

Re: [PHP-DEV] Type casting syntax

[Nikita Popov]

On Sat, Jul 10, 2021 at 11:10 AM Max Semenik  wrote:

> I've been thinking about extending PHP's cast syntax to user-defined types,
> e.g. not only (int)$foo but also (MyClass)$foo. Currently, a T_STRING in
> parentheses is always treated as a constant - would it be acceptable to
> hijack this syntax when used in unary operation context, i.e. "(" T_STRING
> ")" expr? If not, any other alternatives?
>

To answer your question without commenting on the wider discussion: No,
it's not possible to use this syntax. C-style cast syntax is hopelessly
ambiguous -- there's a reason why modern languages always pick a different
syntax for type casts.

To give a simple example, (MyClass) (CastArg) is already valid PHP syntax
and performs a call to the function stored in constant MyClass, with the
argument CastArg.

Regards,
Nikita