Re: [PHP-DEV] [RFC] Enumerations

[Larry Garfield]

Dec 4, 2020 7:37:51 PM Paul Crovella :

> On Fri, Dec 4, 2020 at 3:25 PM Larry Garfield  wrote:
>> 
>> Greetings, denizens of Internals!
>> 
>> Ilija Tovilo and I have been working for the last few months on adding 
>> support for enumerations and algebraic data types to PHP.  This is a 
>> not-small task, so we've broken it up into several stages.  The first stage, 
>> unit enumerations, are just about ready for public review and discussion.
>> 
>> The overarching plan (for context, NOT the thing to comment on right now) is 
>> here: https://wiki.php.net/rfc/adts
>> 
>> The first step, for unit enumerations, is here:
>> 
>> https://wiki.php.net/rfc/enumerations
>> 
>> There's still a few bits we're sorting out and the implementation is mostly 
>> done, but not 100% complete.  Still, it's far enough along to start a 
>> discussion on and get broader feedback on the outstanding nits.
>> 
>> I should note that while the design has been collaborative, credit for the 
>> implementation goes entirely to Ilija.  Blame for any typos in the RFC 
>> itself go entirely to me.
>> 
>> *dons flame-retardant suit*
>> 
>> -- 
>> Larry Garfield
>> la...@garfieldtech.com
> 
> I'd like to see the specific reasons for the restrictions listed in
> Comparison to objects[1]. In general if something's value is even
> debatable then the default position should be to remain consistent
> with the rest of the language. It should take a strong argument to
> introduce any artificial limitation and it's useful to have that in
> the RFC.
> 
> [1] https://wiki.php.net/rfc/enumerations#comparison_to_objects
> 
The reasoning general comes down to one of 2 things:

* they involve state, and enum cases have no state. They may get reintroduced 
with tagged unions, but for now methods relating to state would just be 
confusing.
* we couldn't figure out what possible use they'd have (like static methods on 
cases, which without data are exactly the same as normal methods.)

--Larry Garfield

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

Re: [PHP-DEV] [RFC] Enumerations

[Paul Crovella]

On Fri, Dec 4, 2020 at 3:25 PM Larry Garfield  wrote:
>
> Greetings, denizens of Internals!
>
> Ilija Tovilo and I have been working for the last few months on adding 
> support for enumerations and algebraic data types to PHP.  This is a 
> not-small task, so we've broken it up into several stages.  The first stage, 
> unit enumerations, are just about ready for public review and discussion.
>
> The overarching plan (for context, NOT the thing to comment on right now) is 
> here: https://wiki.php.net/rfc/adts
>
> The first step, for unit enumerations, is here:
>
> https://wiki.php.net/rfc/enumerations
>
> There's still a few bits we're sorting out and the implementation is mostly 
> done, but not 100% complete.  Still, it's far enough along to start a 
> discussion on and get broader feedback on the outstanding nits.
>
> I should note that while the design has been collaborative, credit for the 
> implementation goes entirely to Ilija.  Blame for any typos in the RFC itself 
> go entirely to me.
>
> *dons flame-retardant suit*
>
> --
>   Larry Garfield
>   la...@garfieldtech.com

I'd like to see the specific reasons for the restrictions listed in
Comparison to objects[1]. In general if something's value is even
debatable then the default position should be to remain consistent
with the rest of the language. It should take a strong argument to
introduce any artificial limitation and it's useful to have that in
the RFC.

[1] https://wiki.php.net/rfc/enumerations#comparison_to_objects

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

[PHP-DEV] [RFC] Enumerations

[Larry Garfield]

Greetings, denizens of Internals!

Ilija Tovilo and I have been working for the last few months on adding support 
for enumerations and algebraic data types to PHP.  This is a not-small task, so 
we've broken it up into several stages.  The first stage, unit enumerations, 
are just about ready for public review and discussion.

The overarching plan (for context, NOT the thing to comment on right now) is 
here: https://wiki.php.net/rfc/adts

The first step, for unit enumerations, is here:

https://wiki.php.net/rfc/enumerations

There's still a few bits we're sorting out and the implementation is mostly 
done, but not 100% complete.  Still, it's far enough along to start a 
discussion on and get broader feedback on the outstanding nits.

I should note that while the design has been collaborative, credit for the 
implementation goes entirely to Ilija.  Blame for any typos in the RFC itself 
go entirely to me.

*dons flame-retardant suit*

-- 
  Larry Garfield
  la...@garfieldtech.com

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

Re: [PHP-DEV] [RFC] Restrict $GLOBALS usage

[Sebastian Bergmann]

Am 04.12.2020 um 11:52 schrieb Nikita Popov:

https://wiki.php.net/rfc/restrict_globals_usage


Yes, please. The code you found in PHPUnit (both PHPUnit itself as well as 
sebastian/global-state) that would be affected by this can probably be 
removed (in a future version of PHPUnit that requires PHP >= 8.1).


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

Re: [PHP-DEV] [RFC] Restrict $GLOBALS usage

[Paul M. Jones]

> On Dec 4, 2020, at 04:52, Nikita Popov  wrote:
> 
> Hi internals,
> 
> I would like to propose the following RFC, which restricts certain rare
> usages of $GLOBALS. This change will improve performance, reduce internal
> implementation complexity, and fix a very large class of bugs relating to
> $GLOBALS handling in internal functions.
> 
> https://wiki.php.net/rfc/restrict_globals_usage
> 

Big +1


-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

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

[PHP-DEV] Re: Pass file handle in XMLReader

[Christoph M. Becker]

On 04.12.2020 at 13:35, Aimeos | Norbert Sendetzky wrote:

> Am 04.12.20 um 13:23 schrieb Christoph M. Becker:
>
>> For clarity, it might be preferable to introduce a new static creation
>> method for this.  The implementation could probably use
>> xmlReaderForIO()[1], instead of xmlReaderForFile().
>
> Wouldn't xmlReaderForFd() be more suitable or is this only for file
> handles, not for streams?

xmlReaderForFd() is only for file descriptors; PHP streams are more general.

> What would be a good name for the new method? XMLReader::stream()?

Maybe XMLReader::createForStream(), but I think the name is secondary;
someone would have to come up at least with a draft implementation first.

Regards,
Christoph

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

[PHP-DEV] Re: Pass file handle in XMLReader

[Aimeos | Norbert Sendetzky]

Am 04.12.20 um 13:23 schrieb Christoph M. Becker:
> For clarity, it might be preferable to introduce a new static creation
> method for this.  The implementation could probably use
> xmlReaderForIO()[1], instead of xmlReaderForFile().

Wouldn't xmlReaderForFd() be more suitable or is this only for file
handles, not for streams?

What would be a good name for the new method? XMLReader::stream()?

Best,


Norbert

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

[PHP-DEV] Re: Pass file handle in XMLReader

[Christoph M. Becker]

On 02.12.2020 at 18:17, Aimeos | Norbert Sendetzky wrote:

> The XMLReader object only allows a file name in the constructor and the
> open() method. While this is OK most of the time, files stored at cloud
> services not accessible via an URL must be downloaded first. For big
> files (e.g 100MB to 1GB and more), this requires a lot of time and
> resources.
>
> If the XMLReader would be able accept a file handle too, we could pass
> the handle of a stream to the methods and the XMLReader could process
> the XML data on the fly without the need of a local copy.
>
> Is it possible to allow a file handle in the existing methods or is a
> new one required due to type or other constraints like implementation
> difficulties?
>
> The open() method is implemented here:
>
> https://github.com/php/php-src/blob/faea5ab837ab6393c8821f85cf8abe2723593e8e/ext/xmlreader/php_xmlreader.c#L835-L887

For clarity, it might be preferable to introduce a new static creation
method for this.  The implementation could probably use
xmlReaderForIO()[1], instead of xmlReaderForFile().

[1]

Re: [PHP-DEV] [RFC] Restrict $GLOBALS usage

[Hans Henrik Bergan]

if this gets rid of a significant amount of implementation complexity
or runtime overhead, i'm all for it, and don't think i've ever seen
code like $GLOBALS = []; before,

given that it's technically a BC break, would have been nice as a
8.0.0 thing, but i hope it's small enough for an 8.x instead of
waiting for php9

On Fri, 4 Dec 2020 at 12:04, Nicolas Grekas
 wrote:
>
> Hello Nikita,
>
>
> > I would like to propose the following RFC, which restricts certain rare
> > usages of $GLOBALS. This change will improve performance, reduce internal
> > implementation complexity, and fix a very large class of bugs relating to
> > $GLOBALS handling in internal functions.
> >
> > https://wiki.php.net/rfc/restrict_globals_usage
>
>
> Yes please! This will allow removing some black magic from Symfony's
> VarDumper component, which detects these "copies" of $GLOBALS:
> https://github.com/symfony/symfony/blob/31ee43a8c67897a2f61782060965f5c8a81f58a2/src/Symfony/Component/VarDumper/Cloner/VarCloner.php#L144-L155
>
> Nicolas

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

[PHP-DEV] Re: [RFC] Restrict $GLOBALS usage

[Christoph M. Becker]

On 04.12.2020 at 11:52, Nikita Popov wrote:

> I would like to propose the following RFC, which restricts certain rare
> usages of $GLOBALS. This change will improve performance, reduce internal
> implementation complexity, and fix a very large class of bugs relating to
> $GLOBALS handling in internal functions.
>
> https://wiki.php.net/rfc/restrict_globals_usage

In my opinion, especially the last reason (fixing and preventing bugs
related to missing IS_INDIRECT handling) makes this change particularly
desireable.

Regards,
Christoph

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

[PHP-DEV] Re: Missing warning for stats(), etc. when invoked with empty string

[Christoph M. Becker]

On 03.12.2020 at 11:20, Claude Pache wrote:

> `stats()` and friends invoked with empty string or null as argument, return 
> `false` (indicating failure), but do not emit the Warning that is expected on 
> failure. See: https://3v4l.org/jXC2N 
>
> That discrepancy between the two ways of indicating failure is problematic. 
> Indeed, whenever I use one of those functions without prefixing it by @, I 
> expect that it will either return a value of expected type (`array` in case 
> of `stats()`), or run the panic procedure of my error handler.
>
> I propose to ensure that those functions always emit a Warning in each and 
> every situation they return false/null (provided, of course, that those 
> functions are not supposed to return `false/null` in absence of failure, and 
> that their purpose is not to check failure condition as in `file_exists()`).

Returning false without raising a warning has been introduced[1] to fix
bug #21410[2].  The problem back then was that without that early
return, on Windows the empty string gave erroneous stat() results, and
filetype("") returned "dir".  This is no longer the case at least as of
PHP 7.3.0 (I didn't test older versions); instead after reverting
560e33968d I now get:

Warning: stat(): stat failed for  in %s on line %d
bool(false)

So, yes, I think we should revert that commit.

[1] 
[2] 

Regards,
Christoph

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

Re: [PHP-DEV] Missing warning for stat(), etc. when invoked with empty string

[Nikita Popov]

On Fri, Dec 4, 2020 at 9:33 AM Claude Pache  wrote:

>
>
> > Le 3 déc. 2020 à 22:05, Levi Morrison  a
> écrit :
> >
> > This is a long-standing behavior. Further, I don't know many people
> > who want _more_ warnings in their codebase.
>
>
> My guess is that this position was already discussed in the occasion of
> the several past RFC whose main purpose was to introduce more
> warnings/errors/exceptions? [1], [2], [3], etc. Apparently, many people do
> want more warnings...
>

This is getting a bit off-topic, but I think it's necessary to clarify:
What many of us actually want is *less* warnings. Having less warnings can
take the form of converting them to exceptions, or take the form of
removing them entirely. Both of these things happen, but the conversions to
exceptions tend to be the more controversial and thus take the spotlight.

I'm personally not a fan of warnings thrown by stream/FS functions
(especially when backed by socket streams), as robust code just ends up
having to suppress them all. Unfortunately I can't say that these warnings
are entirely useless, as they *are* helpful for debugging. It would be nice
if PHP had a stronger separation between "this is an error" warnings and
"this is informational" warnings. Things are slowly moving in this
direction with the first category being partially converted into
exceptions...

But well, that's a global problem. The current stance of stream/FS
functions is very much that all error conditions should warn.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Restrict $GLOBALS usage

[Nicolas Grekas]

Hello Nikita,


> I would like to propose the following RFC, which restricts certain rare
> usages of $GLOBALS. This change will improve performance, reduce internal
> implementation complexity, and fix a very large class of bugs relating to
> $GLOBALS handling in internal functions.
>
> https://wiki.php.net/rfc/restrict_globals_usage


Yes please! This will allow removing some black magic from Symfony's
VarDumper component, which detects these "copies" of $GLOBALS:
https://github.com/symfony/symfony/blob/31ee43a8c67897a2f61782060965f5c8a81f58a2/src/Symfony/Component/VarDumper/Cloner/VarCloner.php#L144-L155

Nicolas

[PHP-DEV] [RFC] Restrict $GLOBALS usage

[Nikita Popov]

Hi internals,

I would like to propose the following RFC, which restricts certain rare
usages of $GLOBALS. This change will improve performance, reduce internal
implementation complexity, and fix a very large class of bugs relating to
$GLOBALS handling in internal functions.

https://wiki.php.net/rfc/restrict_globals_usage

Regards,
Nikita

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

[Rowan Tommins]

On 04/12/2020 00:57, Stanislav Malyshev wrote:


You may assert anything, but it's a fact that PHP functions have 
returned nulls on bad values since forever.



I'm not disputing that. I'm disputing that anyone looking at the name or 
documentation of this particular function would guess that "foo\0bar" is 
a "bad value". Clearly, somebody thought so and accounted for it as such 
in the implementation, but it would never have occurred to me if I 
hadn't read this thread.


Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

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

Re: [PHP-DEV] Missing warning for stat(), etc. when invoked with empty string

[Claude Pache]

> Le 3 déc. 2020 à 22:05, Levi Morrison  a écrit :
> 
> This is a long-standing behavior. Further, I don't know many people
> who want _more_ warnings in their codebase.


My guess is that this position was already discussed in the occasion of the 
several past RFC whose main purpose was to introduce more 
warnings/errors/exceptions? [1], [2], [3], etc. Apparently, many people do want 
more warnings...

But my main point is not exactly that. It is inconsistency in behaviour, that 
leads to wrong assumptions, that leads to incorrect code. As another example, 
see the faulty `@is_file( $data ) === false` check mentioned in the other 
thread [4].

Precisely (and I realise that maybe I wasn’t explicit enough in my message), 
the issue is that `stat("non/existent/file")` raises a warning and returns 
false, that leads to the wrong assumption that `stat($random_string)` raises a 
warning whenever it returns `false` instead of an array, that leads to the 
deceptive confidence that the `false` case will be always handled by the error 
handler.

—Claude

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

[2]: https://wiki.php.net/rfc/notice-for-non-valid-array-container 

[3]: https://wiki.php.net/rfc/magic-methods-signature 


[4]: https://externals.io/message/112333#112350