Re: [PHP-DEV] Nullsafe array access can still emit a warning

[Gert de Pagter]

`$undefined?->bar()` does feel wrong, but `$arr[0]?->bar()` does not to me.

But maybe i've just been using javascript too much lately

On Wed, 24 Aug 2022 at 15:11, Marco Pivetta  wrote:
>
> Hey Gert,
>
> On Wed, 24 Aug 2022 at 14:59, Gert de Pagter  wrote:
>>
>> Hi Internals,
>>
>> I recently learned that using null safe on an array access can still
>> emit a warning when the array access is not defined. I kinda expected
>> it to work like a null coalesce and just short circuit there,without
>> the warning.
>>
>> Is there any chance this behaviour could be changed in a n upcoming
>> PHP version? I didn't see anything mentioned specifically about this
>> in the RFC.
>>
>> https://3v4l.org/1raa8
>>
>> Greetings,
>> Gert de Pagter/ BackEndTea
>
>
> This seems expected behavior to me: it's "nullsafe", not "undefinedsafe".
>
> If it operated like `??`, then `$undefined?->bar()` would be valid too, which 
> seems wrong, IMO.
>
> Marco Pivetta
>
> https://twitter.com/Ocramius
>
> https://ocramius.github.io/
>

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

[PHP-DEV] Nullsafe array access can still emit a warning

[Gert de Pagter]

Hi Internals,

I recently learned that using null safe on an array access can still
emit a warning when the array access is not defined. I kinda expected
it to work like a null coalesce and just short circuit there,without
the warning.

Is there any chance this behaviour could be changed in a n upcoming
PHP version? I didn't see anything mentioned specifically about this
in the RFC.

https://3v4l.org/1raa8

Greetings,
Gert de Pagter/ BackEndTea

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

[PHP-DEV] [RFC Proposal] Allow methods to 'become' static

[Gert de Pagter]

Hey Internals,

Recently i've been working on an older code base, where we have a lot
of classes with all
static methods. We've been moving to injecting the classes, and
calling the methods as if they
were not static.

I wanted to add interfaces to these classes, with non static methods,
so we can pretend in our implementation they are not static, and allow
us to easier switch to non static methods in the future.

This is (currently) not allowed by the language: https://3v4l.org/WKdvM
Is there any chance of this being possible in future versions of PHP?
This would only allow 'normal' methods to become static. Making static
methods non static would break Liskov substitution principle in PHP as
you may not be able to call the method in the same way. This means you
can't have a 'normal' method become static in an inherited class, and
then become 'normal' again in another inherited class. This works the
same way with co/contra-variance in return/parameter types:
(https://3v4l.org/j1SO9)

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

[PHP-DEV] RFC karma

[Gert de Pagter]

Hey Internals,

I’d like RFC karma in order to write an RFC on intersection types.

Could someone give me the need permissions?

Thanks in advance!

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

[PHP-DEV] Intersection types

[Gert de Pagter]

Hi Internals,

With recent additions of the type system like union types [1], id like to 
propose adding intersection types as well.

Looking through past RFCs I found one from 2016 [2] which never left the 
discussion phase and is currently marked as inactive.
Before continuing with an RFC I'd like to know if there are any particular 
reasons why the original RFC never got into a voting phase, so that this one 
may be more successful.

P.S. I’d also like to get RFC karma so I could create a proposal.

Thanks in advance!


[1] https://wiki.php.net/rfc/union_types_v2 

[2] https://wiki.php.net/rfc/intersection_types 

Re: [PHP-DEV] Warn when declaring required parameter after optionalone

[Gert]

> I could understand a warning or deprecation in a minor release, but as
there's already so many engine level exceptions landing in 8.0, I think
it makes sense to throw this on the pile as well to be swept up in the
same pass of migrations that people do in preperation for 8.0.

If this would've generated a warning in 7.4 then making this a compile
time error is acceptable.
But going from nothing to an error without any kind of warning makes
the upgrade harder than it needs to be.
I think this should be a warning, and then an exception in 9.0. Unless
there is gonna be a PHP 7.5
where only deprecations get added, in that case an error in 8.0 would be fine.

--
Gert

On Thu, 9 Jan 2020 at 15:06, Mark Randall  wrote:
>
> On 09/01/2020 12:31, Sebastian Bergmann wrote:
> > I would prefer erroring out over just emitting a warning.
>
> I'm in agreement with Sebastian, a compile time error is the way to go.
>
> I could understand a warning or deprecation in a minor release, but as
> there's already so many engine level exceptions landing in 8.0, I think
> it makes sense to throw this on the pile as well to be swept up in the
> same pass of migrations that people do in preperation for 8.0.
>
> Better to get the pain over and done with, rather than drag it out over
> multiple versions, as I'd guess that even if it was a warning now, it
> would end up a compile error a few years from now.
>
> --
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] [VOTE] Reclassifying engine warnings

[Gert]

I may be a bit late to this party, but will the promotion to error
exception of illegal offsets also happen for using resources as array
keys? These currently produce a notice, and are then casted to an
integer: https://3v4l.org/cQ8hf
Or will the behaviour of that remain the same?

On Fri, 11 Oct 2019 at 18:16, Claude Pache  wrote:
>
>
>
> > Le 11 oct. 2019 à 11:12, Olumide Samson  a écrit :
> >
> > On Fri, Oct 11, 2019, 9:29 AM Benjamin Morel 
> > wrote:
> >
> >>>
> >>> As people have expressed interest in hearing about direct technical
> >>> benefits that these kinds of changes have ... let me give you an example
> >>> that came up yesterday.
> >>
> >>
> >>
> >> Too bad this example comes after the vote has been made, and failed.
> >> This would be a very strong argument in favour of using exceptions
> >> everywhere in the next major version: codebase cleanup, room for more
> >> optimization.
> >>
> >> Nikita, please fork PHP, we'll follow you ;-)
> >>
> >> — Benjamin
> >>
> >
> > I think I'm always available to contribute to a fork of a better PHP, coz I
> > love the syntax not the garbages included in the current one.
>
> If you’re seeking a fork of PHP that wilfully breaks BC for the sake of 
> cleanup and optimisation, you should seriously consider Hack. Although I 
> don’t know whether they’ve already removed support of the appalling implicit 
> initialisation of  variables to `null`, or of the dreadful backtick operator, 
> you’ll be delighted to learn that they’re on the process of removing 
> references, PHP arrays (in favour of Hack arrays and collections), and even 
> that little pesky ` ;-)
>
> https://hhvm.com/blog/2019/02/11/hhvm-4.0.0.html 
> 
>
> Enjoy. (But not with me: our company does not have the budget to migrate 30 
> Mo of code without counting external libraries.)
>
> —Claude
>
>

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

Re: [PHP-DEV] Warning for "confusable" types

[Gert]

On that note, since traits aren't possible as a return type. Would it
be possible to determine that the given return type is a trait? In
that case a more specific error message could also be possible.
I don't know much of the internals, so i don't know if that is even
possible atm, but it would be a nice addition.

On Mon, 14 Oct 2019 at 09:53, Stanislav Malyshev  wrote:
>
> Hi!
>
> > I was about to give my +1 on the more generic approach, but type hints
> > could also be interfaces and "instance of the class X" is not a good fit.
>
> We could use "class or interface" if that's important.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] XML Validation

[Gert]

Is this something that would need an RFC?

I'd be willing to take a shot at it myself, but my C experience is
rather limited, so i'm not sure if i could cook up an implementation.


On Mon, 23 Sep 2019 at 09:44, Benjamin Eberlei  wrote:
>
> Hi Gert,
>
> On Mon, Sep 23, 2019 at 9:38 AM Gert  wrote:
>>
>> Hi Internals,
>>
>> I've been working with XML and validation recently, and the Dom
>> classes do basically everything that is needed. The only thing is that
>> to get the errors of the schema validation we call the
>> `validateSchema` on the DomDocument, and then use the
>> `libxml_get_errors` function to actually get the errors.
>>
>> I'd like to propose either adding a flag to the `validateSchema` to
>> make it throw an error detailing the actual XML errors, or adding a
>> new function that validates and throws with all errors.
>>
>> I'd like to do the same with `schemaValidateSource` as well.
>>
>> Do you think this is something that should be added to PHP itself, or
>> is it something that should be solved by third party packages?
>
>
> this is something that should be added to PHP's dom classes, but the C 
> development always takes longer than a userland library.
>
> If you please add a ticket on https://bugs.php.net, for this I will consider 
> it for ext/dom, as I think it would be very useful for PHP 8 to go away from 
> the warnings and libxml error handling approach to something better as you 
> suggest.
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>

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

[PHP-DEV] XML Validation

[Gert]

Hi Internals,

I've been working with XML and validation recently, and the Dom
classes do basically everything that is needed. The only thing is that
to get the errors of the schema validation we call the
`validateSchema` on the DomDocument, and then use the
`libxml_get_errors` function to actually get the errors.

I'd like to propose either adding a flag to the `validateSchema` to
make it throw an error detailing the actual XML errors, or adding a
new function that validates and throws with all errors.

I'd like to do the same with `schemaValidateSource` as well.

Do you think this is something that should be added to PHP itself, or
is it something that should be solved by third party packages?

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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Gert]

Maybe i'm misunderstanding something here, but what does turning
notices into deprecations achieve? Because if you have deprecation
notices being logged then it shouldn't be extra work to log
notices/warnings as well right?

On Wed, 28 Aug 2019 at 16:16, Chase Peeler  wrote:
>
> Well, one reason I was so vocal about short tags wasn't a love for short
> tags themselves. It wasn't even to prevent the detrimental effects of
> removing them. Honestly, the 2nd RFC wasn't a horrible option. It was more
> about the precedent that it set - pushing huge BC breaks on the users (most
> of which are voiceless in the process, because they aren't involved in the
> community at all, most not really aware there is anything to be involved
> with) with little, if any, positive gain.
>
> Let's see how this plays out a bit longer. It's too early to tell if it's a
> dying attempt to keep pushing those type of changes, which are destined to
> be rejected, or, evidence that we are still in danger of having such a
> precedent set.
>
>
>
> On Wed, Aug 28, 2019 at 10:11 AM Chase Peeler  wrote:
>
> >
> >
> > On Wed, Aug 28, 2019 at 9:55 AM Reindl Harald 
> > wrote:
> >
> >>
> >>
> >> Am 28.08.19 um 15:48 schrieb Chase Peeler:
> >> > If it is still done, then I think a deprecation path is a must. As
> >> > mentioned earlier, this doesn't necessarily mean E_DEPRECATION messages
> >> -
> >> > warnings will work too. The key is that error logs with more urgency
> >> than
> >> > notices are created that users can use to track down and fix issues.
> >>
> >> hell, there are notices for at least a decade
> >>
> >> error_log = "/var/log/php_error.log"
> >> error_reporting = E_ALL
> >> display_errors = 1
> >>
> >> this is my development *as well* production config on every machine
> >> since 16 years now and every warning/notice get fixed because every 30
> >> minutes the errorlog get mailed to every developer and admin
> >>
> >> turn logging on and start cleanup what you would have had a decade time.
> >
> >
> > Am I the only one getting tired of people telling me how I need to operate
> > just like they do? Everyone's circumstances are different. Just because
> > something is easy for you, or works well for you, doesn't mean it's easy or
> > even feasible for someone else. I've learned it's useless to try to explain
> > how my situation might not be exactly like everyone else's, so I'm not
> > going to waste the time doing it again.
> >
> > Why can't anyone see that taking on these myopic "My situation is the only
> > valid situation" views are going to kill this language.
> >
> > "I always initialize my variables, so, it's no big deal if everyone else
> > is forced to do so."
> > "I was able to find and replace all the short tags in my code in 5
> > minutes, so it should be easy for everyone else to do as well."
> > "We fix every single notice within 30 minutes of it popping up in a log.
> > You should be able to do that as well."
> > etc. etc. etc.
> >
> > Also, if you are going to try and tell me how I should my job, at least
> > have the guts to reply to the entire list instead of sending it to me in a
> > private reply. I'm obviously not afraid to turn around to make your reply
> > public, so it'll save everyone a bit of time.
> >
> > --
> > Chase Peeler
> > chasepee...@gmail.com
> >
>
>
> --
> Chase Peeler
> chasepee...@gmail.com

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

[PHP-DEV] Error instead of returning false

[Gert]

Hello internals,

I wanted to propose an RFC, but i'd like to check first if this idea
has been considered before already.

My idea, extremely summarized, would be to take the functions that
return false/null when they 'error', and instead make them actually
throw an error.

Currently, functions like getcwd or json_decode will return false/null
when an error occurs, and they populate a global error state, which
can be retrieved by error_get_last, or similar functions. json_decode
already got the JSON_THROW_ON_ERROR option in PHP 7.3, and this RFC
would basically make that behaviour default. This RFC would target PHP
8.0, but i'd like to hear some opinions on this.

Greetings,
Gert de Pagter (BackEndTea)

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

Re: [PHP-DEV] open_basedir?

[Gert]

Hello,

If the plan is to remove it in 8.0, then i'd say its beneficial to already
deprecate it in 7.4. This will give users an earlier warning that these
upgrades need to happen.

Cheers

On Tue, 7 May 2019 at 12:18, Joe Watkins  wrote:

> Morning Nikita,
>
> It would be wise to do a) and b) regardless of whether it's going to be
> removed.
>
> I think +1 on removing it in 8 ... I'm not sure if it should be deprecated
> in 7.4 first, or how that would work ?
>
> Cheers
> Joe
>
> On Tue, 7 May 2019 at 12:11, Nikita Popov  wrote:
>
> > Hi internals,
> >
> > The open_basedir ini setting has two significant problems:
> >
> > 1. It is a major performance hit, because it disables the realpath cache.
> >
> > 2. Many people think it is a security feature and use it as such.
> However,
> > open_basedir is in reality a "best effort" mechanism, with known
> > workarounds and more regularly being found. Especially when it comes to
> > interactions with 3rd party libraries, enforcing open_basedir is simply
> > impossible.
> >
> > What open_basedir tries to do must be implemented on the operating system
> > level to work reliably (and of course such mechanisms exist, such as
> jails,
> > chroot and friends).
> >
> > I wonder if it is feasible to drop this ini setting? Enforcing this
> doesn't
> > really seem like any of PHP's business. If not, I think we need to at
> least
> >
> > a) make it clear in the documentation that this is *not* a security
> option
> > and only exists to prevent "accidents" and
> > b) update the security policy (https://wiki.php.net/security) to state
> > that
> > open_basedir bypasses are not security issues. I believe this has been
> part
> > of Debian's security policy for some time already.
> >
> > Regards,
> > Nikita
> >
>