Re: [PHP-DEV] Type casting syntax

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

Re: [PHP-DEV] Type casting syntax

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

Re: [PHP-DEV] Type casting syntax

> 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

Re: [PHP-DEV] Type casting syntax

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

Re: [PHP-DEV] Type casting syntax

> 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 >

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

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

Re: [PHP-DEV] Type casting syntax

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

Re: [PHP-DEV] Type casting syntax

> 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

Re: [PHP-DEV] Re: open_basedir?

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

Re: [PHP-DEV] Type casting syntax

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

Re: [PHP-DEV] Type casting syntax

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.

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

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:

Re: [PHP-DEV] Type casting syntax

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.

Re: [PHP-DEV] Re: open_basedir?

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

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

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

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

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

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

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

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

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

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.

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

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 >

Re: [PHP-DEV] Fake Closure Comparison

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,

Re: [PHP-DEV] Fake Closure Comparison

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

[PHP-DEV] Bundled Extension namespace(s)

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

Re: [PHP-DEV] Fake Closure Comparison

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

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

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

Re: [PHP-DEV] Type casting syntax

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