[PHP-DEV] Re: [RFC] Unicode Text Processing

[Paul Crovella]

On 12/15/2022 7:34 AM, Derick Rethans wrote:

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


A few quick thoughts:


The constructor will also convert the given text to Unicode Canonical Form.


By this do you mean Normalization Form C (NFC)? "Unicode Canonical Form" 
isn't a phrase I'm familiar with.


Assuming so, are modified texts (e.g. via join, replaceText, reverse) 
re-normalized?


---


The constructor will also strip out a BOM (Byte-Order-Mark) character, if 
present.


This is also known as ZWNBSP (Zero Width No-Break Space). Will only a 
leading instance be stripped? If so, how can someone search for it (or a 
substring beginning with it) given that:



If an argument to any of the methods is listed as string|Text, passing in a 
string value will have the same semantics as replacing the passed value with 
new Text($string).


and all the search methods take `string|Text $search`.

---

Why is this being introduced directly into PHP core rather than first an 
extension where it's easier to shake out the interface and behavior?


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

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Paul Crovella]

On 8/26/2022 1:28 AM, Peter Bowyer wrote:

Hi Juan,

On Thu, 25 Aug 2022 at 17:02, juan carlos morales <
dev.juan.mora...@gmail.com> wrote:


RFC: https://wiki.php.net/rfc/json_validate



Thanks for bringing forward this RFC. I am in favour of this change, as you
can't efficiently validate JSON in userland.

Like Rowan I'm not convinced JSON_THROW_ON_ERROR belongs here. I can't
think of a case where more than a boolean response is needed.

Peter




I'm for this as well. Though something more than a boolean is useful to 
indicate when the max depth has been exceeded as that's not strictly a 
problem with the json's validity.



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

[PHP-DEV] Re: [Concept] Extension methods

[Paul Crovella]

On 8/10/2022 7:17 AM, Alex Wells wrote:

This solution works, but in practice is rarely used. The reasons are:
- there's no IDE completion: `$collection-> ` <- here I want IDE to
auto-complete the `map` method somehow, but since it's a function this is
impossible


This isn't impossible. There's nothing stopping an IDE from seeing 
`$collection->` and suggesting/completing that with `map($collection, ` 
- they just don't right now. Offhand I don't see why this would be more 
difficult for them to implement than support for extension methods. As a 
bonus it'd work with existing functions.



- it's ugly looking and hard to read:
`getPromotions(mostExpensiveItem(getShoppingList(getCurrentUser(),
'wishlist'), ['exclude' => 'onSale']), $holiday);`


It's easy to write ugly looking code using any particular syntax. It's 
unconvincing to do so. Instead of rehashing it all here I'd suggest 
looking back at examples and counter-examples of exactly this sort of 
thing in past pipe operator discussions.


In short every ugly example has a fine, easy-to-read way of writing it 
now in existing code. A useful readability comparison would pit the new 
feature against the best looking version of example code you can come up 
with rather than the worst. Without that you're not really demonstrating 
improvement.


The most an ugly example has done for a proposal is generate noise.


- it's easy to mess up the order of arguments


An extension method would shift a single argument from inside 
parentheses to the left of the function name. It just moves it. I don't 
see any impact here.



The pipe operator RFC [1] was trying to solve that but got rejected.


This is essentially making `->` the pipe operator with extra steps 
(`extension`/`use extension`) and less utility (not working on existing 
functions.)


Considering all the conflict resolution stuff would have to be done 
anyway you may as well drop the extra steps and explore `->` as a pipe 
operator directly. Only add in extension/use extension if there's a 
blocker they solve - i.e. when they provide real value.




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

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Paul Crovella]

On Thu, Mar 3, 2022 at 8:51 PM G. P. B.  wrote:
>
> Moreover, at the time of writing this, none of the following programming
> languages have any messages in regards to the war:
> - Python (https://www.python.org/)
> - TypeScript (https://www.typescriptlang.org/)
> - Rust (https://www.rust-lang.org/)

I know at least Rust[1] does, dunno about the others.

[1] https://blog.rust-lang.org/2022/02/24/Rust-1.59.0.html

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

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Paul Crovella]

On Wed, Mar 2, 2022 at 1:08 PM Stanislav Malyshev  wrote:
>
> That said, if somebody were to design a logo version with Ukraine flag
>

In case anyone has use for it: https://svgshare.com/i/epJ.svg

Colors are #0057b7 and #ffd700, from
https://en.wikipedia.org/wiki/Flag_of_Ukraine#Design, with a white
stroke.

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

Re: [PHP-DEV] [VOTE] Locale-independent case conversion

[Paul Crovella]

On Thu, Nov 25, 2021 at 3:14 AM Tim Starling  wrote:
>
> On 25/11/21 7:57 pm, Côme Chilliet wrote:
>
> > To reuse the example from the RFC, if I want to convert a UTF string to 
> > uppercase using Turkish rules and get dotted capital I, what should I use?
>
> For case-insensitive comparison you can use Collator. But for display
> you just have to do it yourself. For the Turkish Wikipedia and other
> Turkic language websites we are currently using str_replace().

Any particular reason not to use transliterators? https://3v4l.org/I038T

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

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Paul Crovella]

On Fri, Nov 12, 2021 at 5:08 AM Nikita Popov  wrote:
>
> Hi internals,
>
> I've opened the vote on
> https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
> 2021-11-26.
>
> Regards,
> Nikita

In the Motivation section when talking about static analysis the RFC
makes the claim:

> The #[AllowDynamicProperties] attribute proposed in this RFC makes the cases 
> where dynamic properties are used intentionally explicit.

however this really isn't true as the attribute is on the class rather
than the use. Static analysis will still have no idea whether any
dynamic property assignment is indeed a bug or intentional. The
information added is only whether the author of the class has deemed
it okay for dynamic properties to be used on it, not by it. The class
author and the dynamic property user might not be the same person or
have any relation. The class being intentionally used with dynamic
properties is not necessarily in the user's control. Similarly the
class being unintentionally used with dynamic properties may not be
either.

This user/used mismatch is repeated in the RFC, for example:

> Classes marked with #[AllowDynamicProperties] as well as their children can 
> continue using dynamic properties without deprecation or removal.

These classes cannot then use dynamic properties, they can have
dynamic properties used on them.

The inaccurate prevention claim is repeated as well:

> #[AllowDynamicProperties] requires making classes that rely on dynamic 
> properties explicit and prevents accidental use of dynamic properties

It may help prevent some, but others can skate through on happenstance.

Cheers,
Paul

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

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Paul Crovella]

On Wed, Aug 25, 2021 at 3:03 AM Nikita Popov  wrote:
>
> Hi internals,
>
> I'd like to propose the deprecation of "dynamic properties", that is
> properties that have not been declared in the class (stdClass and
> __get/__set excluded, of course):
>
> https://wiki.php.net/rfc/deprecate_dynamic_properties
>
> This has been discussed in various forms in the past, e.g. in
> https://wiki.php.net/rfc/locked-classes as a class modifier and
> https://wiki.php.net/rfc/namespace_scoped_declares /
> https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/-language-evolution.md
> as a declare directive.
>
> This RFC takes the more direct route of deprecating this functionality
> entirely. I expect that this will have relatively little impact on modern
> code (e.g. in Symfony I could fix the vast majority of deprecation warnings
> with a three-line diff), but may have a big impact on legacy code that
> doesn't declare properties at all.
>
> Regards,
> Nikita

I'd like to see a section (or just a paragraph) in the RFC summarizing
the benefits of making this change. Right now the introduction says
that using dynamic properties in modern code "is rarely done
intentionally" implying that it's typically done unintentionally,
however I can't remember the last time I saw unintentional use either.
Is this a common cause of bugs? The internal impact section mentions
saving 8 bytes per object plus an unspecified "dramatic" amount for an
object iterated over via `foreach` which sounds nice but leaves me
guesstimating at real-world impact.

I don't much care for dynamic properties, but I also don't much see
them outside legacy code so they're not bringing me troubles either.
Breaking working code, however, would.

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

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

[Paul Crovella]

On Thu, Jun 17, 2021 at 11:01 PM Craig Francis  wrote:
>
> As there’s been no issues raised with supporting integers, and doing so
> will help adoption, the implementation will be updated to allow them.
>
> Now to choose the name, with the options is_known() from Joe and
> is_trusted() from Moritz:
>
> https://strawpoll.com/bd2qed2xs
>
> Keep in mind it might also become a dedicated type in the future.
>
> Craig

Someone somewhere will end up writing a function that drops their
database when given a 3 that PHP told them to trust.

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

Re: [PHP-DEV] Re: Policy for procedural style in new additions

[Paul Crovella]

On Thu, Jun 3, 2021 at 3:07 PM Christoph M. Becker  wrote:
>
> I'd take a step at a time, and start with "prohibit introduction of new
> dual APIs" only.
>

That sort of RFC doesn't really buy anything. It'd take a 2/3 vote to
override it which is the same as what it'd take to introduce a dual
API in the first place. Drop the ceremony and just add a note to the
wiki.

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

Re: [PHP-DEV] [RFC] Partial function application

[Paul Crovella]

On Fri, May 14, 2021 at 4:44 PM Aaron Piotrowski  wrote:
>
> My issue is the dual-meaning of ? in the current proposal. In `foo(?, 42)`, 
> the ? represents a single argument, but adding a trailing ? (such as in 
> `foo(?, 42, ?)`) represents any number of arguments. Would it perhaps make 
> sense to make superfluous ? markers an error?
>
> foo(?); // Fine, needed to define a partial with no bound args.
> foo(?, 42); // Ok, binds second arg.
> foo(?, ?, 42); // Ok, binds third arg.
> foo(?, 42, ?); // Error, unnecessary placeholder.
> foo(?, ?); // Error, unnecessary placeholder.
>
> The intention here is to keep the syntax unambiguous.
>
> foo(?) == foo(?, ?) == foo(?, ?, ?) and so forth is not going to be obvious 
> to everyone, so why allow meaningless and misleading syntax.
>
> Cheers,
> Aaron Piotrowski
>

While it's my preference not to use superfluous placeholders they do
no real harm and I do not feel comfortable imposing this preference on
others.

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

Re: [PHP-DEV] [RFC] Partial function application

[Paul Crovella]

On Fri, May 14, 2021 at 2:49 PM Aaron Piotrowski  wrote:
>
> Consider `function foo(int $x, int $y, int $z) {}` with a partial defined as 
> `$partial = foo(?, 42)`.
>
> If the partial is called as `$partial(73, 8)`, should 8 be forwarded to `$z` 
> or should the call error as providing too few arguments?

The 8 passes along to $z. There is no error, all required arguments
have been provided.

> Or perhaps should the partial declaration should error, as it should have 
> been `foo(?, 42, ?)` or `foo(?, 42, ...?) so the partial provided all 
> required arguments to foo.

I think this highlights where the misunderstanding of this feature is.
Partial application is about binding arguments. ? isn't an argument,
it's an argument placeholder. It does two things: signals to create a
closure wrapping the function rather than calling it immediately, and
holds a position in the argument list so that an argument further to
the right can be fixed (bound) at that time. Arguments are bound;
argument placeholders are not, they exist only for convenience. The
syntax `foo(?, 42)` doesn't call foo, let alone provide any arguments
to it, it simply creates a closure that'll pass along 42 at the
appropriate argument position along with whatever else it's provided
with.

Requiring additional trailing argument placeholders or adding an
additional token `...?` unnecessarily complicates things, burdens the
user, and only serves to further promote misunderstanding.


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

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

Re: [PHP-DEV] [RFC] Partial function application

[Paul Crovella]

On Sun, Apr 25, 2021 at 12:27 PM Larry Garfield  wrote:
>
> Greetings, Internalians!
>
> I would like to offer for your consideration another RFC, specifically syntax 
> for partial function application.
>
> https://wiki.php.net/rfc/partial_function_application
>
> It includes an implementation by Joe Watkins that is already about 95% 
> complete.  (There's some edge cases he's still sorting out, but all of the 
> typical cases should work already.)  Most of the design work comes from Levi 
> Morrison and Paul Crovella.  I helped out with the tests, a few edge bits, 
> and general instigator/nudge. :-)
>
> Discuss.

Regarding "Comparison to other languages" and "Syntax choices" - I
lifted the design and ? character directly from XQuery, adapting for
PHP's variadic nature.

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

Re: [PHP-DEV] Changes to Git commit workflow

[Paul Crovella]

You might consider requiring commits be signed while you're at it.

On Sun, Mar 28, 2021 at 3:53 PM Nikita Popov  wrote:
>
> Hi everyone,
>
> Yesterday (2021-03-28) two malicious commits were pushed to the php-src
> repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how
> exactly this happened, but everything points towards a compromise of the
> git.php.net server (rather than a compromise of an individual git account).
>
> While investigation is still underway, we have decided that maintaining our
> own git infrastructure is an unnecessary security risk, and that we will
> discontinue the git.php.net server. Instead, the repositories on GitHub,
> which were previously only mirrors, will become canonical. This means that
> changes should be pushed directly to GitHub rather than to git.php.net.
>
> While previously write access to repositories was handled through our
> home-grown karma system, you will now need to be part of the php
> organization on GitHub. If you are not part of the organization yet, or
> don't have access to a repository you should have access to, contact me at
> ni...@php.net with your php.net and GitHub account names, as well as the
> permissions you're currently missing. Membership in the organization
> requires 2FA to be enabled.
>
> This change also means that it is now possible to merge pull requests
> directly from the GitHub web interface.
>
> We're reviewing the repositories for any corruption beyond the two
> referenced commits. Please contact secur...@php.net if you notice anything.
>
> Regards,
> Nikita
>
> [1]:
> https://github.com/php/php-src/commit/c730aa26bd52829a49f2ad284b181b7e82a68d7d
> and
> https://github.com/php/php-src/commit/2b0f239b211c7544ebc7a4cd2c977a5b7a11ed8a

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

Re: [PHP-DEV] Re: [RFC] Phasing out Serializable

[Paul Crovella]

> an RFC that mandates what should happen in 10.0, maybe
> 10 years into the future feels a bit farfetched.

It's more of a default unless another RFC changes the plan rather than
a mandate. Given the plan here it seems a reasonable default.

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

Re: [PHP-DEV] [RFC] Short-match

[Paul Crovella]

On Mon, Dec 14, 2020 at 1:23 PM Sara Golemon  wrote:
>
> On Mon, Dec 14, 2020 at 2:24 PM Doug Nelson  wrote:
>
> > Both you and Sara at different points have talked about thinking was bad
> > practice, but I've not read anything compelling about why it should be
> > considered as such.
> >
> >
> I'm not a full -1 on the concept (especially as match(true) has the
> convenience of returning a value), but it's very square peg in a round hole
> to me.
>
> At the end of the day though, that's a style choice and not one I have any
> business imposing on anyone, and certainly within the context of this diff,
> the actual change is trivial.  It's sugar for match(true) that looks like
> match.  /shrug
>
> I might suggest broadening the scope to include `switch` as well though.
> If we're going to codify match(true) as a pattern, we should at least be
> consistent about it.
>
> -Sara

I lean more on the side of +1 but otherwise agree with Sara here. I'm
apathetic on including switch but it's worth considering.

If this (slightly) better aligns someone's code with how they're
thinking about the problem then yay.

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

Re: [PHP-DEV] [RFC] Enumerations

[Paul Crovella]

On Tue, Dec 8, 2020 at 10:14 AM Larry Garfield  wrote:
>
>
> Hi Paul.  Although we're on hold for a bit while Ilija makes some changes in 
> direction (see previous email)

I'm looking forward to seeing the results.

>
> Enumerations, as a general concept, are stateless.  Or rather, the idea of 
> state doesn't even apply to them.

They're (enumerated) lists of things. You need a way to make a list,
identify an item as being on the list, and differentiate it from other
items on the list.

> The integer 5 doesn't have any state of its own.  All instances of the 
> integer 5 are logically identical to all other instances of the integer 5.

For simple types like integers, sure. Objects however can carry
additional data around without interfering with identifying or
differentiating them. It doesn't matter if object 5 has my address
book, is wearing a funny hat, or just cached the results from a bunch
of expensive method executions - you can still identify it and
distinguish it just fine.

> That the PHP RFC for enums uses objects internally is incidental.

This is a complete reversal from what you've otherwise written in and
about the RFC.

> So if you're defining, say, an enum for cardinal directions (North, South, 
> East, West), There are literally only 4 possible values for that type, and 
> those values must always be equal to themselves.  Attaching "5 miles" to 
> "South" in one script and "2 km" to "South" in another script is nonsensical, 
> just like attaching "feet" to the number 5 and later changing it to "fingers" 
> just doesn't make any sense at all.

Whether or not an object holding other data makes sense is irrelevant
to enums. Take it up in code review.

> It is true that, if you're attaching operations to enum cases that have no 
> state, a method, a static method, and a constant are often interchangeable.  
> A constant is strictly less capable since it cannot have logic, but a method 
> and static method are functionally equivalent.  The reason for forbidding 
> static methods and constants is largely simplicity.

You've significantly added to the WTF factor and edge cases when
working with them. For example enums can implement interfaces. Except
interfaces with constants. Or maybe you can implement interfaces with
constants, you just don't inherit the constants. Wait no that'd break
type declarations. Perhaps then you can inherit constants from
interfaces but you still can't declare them yourself. So the way to
use constants in enums is to declare them on an interface and
implement that to inherit them. Maybe.

This isn't simplicity. None of these options makes working with enums better.

Whether you prefer constants, static methods, or instance methods
isn't even relevant to enums. Again take it up in code review.

> For example, the change I just discussed in my previous email about switching 
> to a single class with instances as constants means that static methods can 
> only be on the enum (Suit), because there is no per-case-class to put them on 
> (Diamonds).  The same is true of per-instance constants.  If we'd promised 
> that those things worked, we wouldn't be able to make this change.

The thing never shipped, you can make any change you want. If you're
pretending it did ship then you couldn't make that change anyway
without breaking instance methods so your point is moot.

> If when the dust settles there's a good reason to expand the functionality 
> further in ways that still don't violate "South === South," (such as adding 
> constants to the enum type itself, perhaps) those can be considered at that 
> time.

As you've said elsewhere:

> Because enums are based on classes, there's not really any added complexity. 
> They inherit the ability to have methods from being classes. It would be more 
> work to separate it.

The same holds for constants, static methods, properties, (traits? do
these even work? some of them?) This isn't about adding functionality,
it's about not arbitrarily removing it.

> As both Rowan and I mentioned, the long-term plan includes future RFCs for 
> other functionality such as tagged unions.  If you want state,

I want a coherent enum RFC that isn't complicated by unrelated
personal preferences being shoehorned into it. If you want to make an
RFC to deprecate class constants in favor of methods - fine, but at
least make the RFC about that. Trying to wedge it in here half-assed
only creates problems.

> then what you want is not an enum but a tagged union.

You're saying this as if they're necessarily different things.

> For whatever reason, most languages with tagged unions seem to build them 
> into and onto enums.

Languages that implemented enums such that they function as tagged
unions saved themselves the effort of making the same thing twice.
They also saved their users from dealing with whatever subtle
differences would've been included to distinguish them.

> I'm not entirely sure why, and I'm honestly not 100% convinced that's the 
> 

Re: [PHP-DEV] [RFC] Enumerations

[Paul Crovella]

On Sun, Dec 6, 2020 at 7:49 AM Larry Garfield  wrote:
>
> On Sun, Dec 6, 2020, at 9:11 AM, Rowan Tommins wrote:
>
> > Note that Larry's longer term plan is for "algebraic data types",
> > including "tagged unions": https://wiki.php.net/rfc/adts Unlike
> > straight-forward enum cases, these are not singletons, and each instance
> > has its own associated state.
>
>
> I was going to respond, but I think Rowan summed it up here.

That's disappointing as he didn't even attempt to address the majority
of my concerns.

> Stateful enums are called tagged unions, and that's a separate phase to keep 
> the implementation and discussion focused for now.

I am only talking about the RFC you presented, you and Rowan are the
ones bringing up others.

> We hope to add those in the future, but for now unit and scalar enums have a 
> ton of value unto themselves.
>
> --Larry Garfield

To be clear I want enums in PHP, I think most people do, which is why
I'd like to see this RFC improved.

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

Re: [PHP-DEV] [RFC] Enumerations

[Paul Crovella]

On Sun, Dec 6, 2020 at 7:12 AM Rowan Tommins  wrote:
>
> On 06/12/2020 00:17, Paul Crovella wrote:
> >> enum cases have no state
> > Unless there's a bit left out from this RFC this is not completely
> > true, you've just limited them to annoying ways of working with data,
> > e.g. static variables.
>
>
> I'm not sure what you mean here, but it sounds a bit like you're saying
> there are ways to emulate mutable state, so why bother restricting it?

Static variables don't emulate mutable state, they are mutable state.
My question is why go out of the way to restrict things arbitrarily,
particularly when the result is ineffective and just makes things suck
more. It's irrelevant extra work to annoy people with no gain.

> The point is that since enum cases are singleton objects, any instance
> state would actually be global across the program, which is probably not
> what people would expect.

Instance state being global is a well-known problem with singletons.
Maybe don't use singletons then. Or simply document them as was done
in the RFC. I'd prefer the former since singletons don't seem to buy
much here but problems, though maybe I'm missing something. In any
case why is static state being (kinda sorta) restricted along with it?

> >> static methods on cases, which without data are exactly the same as normal 
> >> methods
> > This is an argument against instance methods, which you kept, rather
> > than static methods, which you didn't. How is this division anything
> > but arbitrary?
>
>
> On a singleton object, instance methods and late static binding are
> equivalent, but instance methods are probably more intuitive, since
> people are more used to writing code like "$this->suit->shape();" than
> "$this->suit::shape();"
>
> I guess both could be supported, but other than more code style
> decisions to make, I can't think of what they'd add.

Consistency. Which reduces both the wtf factor when working with them
and edge cases for other features that interact with them.

> > Again, what is it particular to enums that necessitates adding these
> > inconsistencies to the language? I get that*you*  want to avoid state,
> > but how is that an enum thing rather than a you thing?
>
>
> "Inconsistency" is a straw man here, because these are a brand new
> concept that already does things objects don't do.

Inconsistency is in no way a straw man. This RFC has enums being
implemented as "fancy objects", based on classes, backed by objects,
with the results being treated as classes and objects in every way
except for.. well mostly a bunch of artificial restrictions that
appear to have nothing to do with enums at all.

> So let's flip it
> around: do you have any use cases for directly storing state on an enum
> case, remembering that such state would be unavoidably global?

No, that is a garbage standard that's been abused around here for too
long. This RFC is proposing to introduce inconsistencies into the
language, it's up to it to justify them. It is not up to me or anyone
else to come along and pass your personal code review just to ask for
that justification.

> Restricting them will likely make other desirable features easier - for
> instance, how would serialization work:

Like serialization already works with objects, including singletons.

> $a = Suit::Hearts;
> $a->setColour(Colour::Pink);
> $serialized = serialize($a); // does this serialize the instance state?
> $a->setColour(Colour::Purple);
> $b = unserialize($serialized);
> assert($a === $b); // as discussed elsewhere, this should be true
> assert($a->getColour() === $b->getColour());  // are they both pink?
> both purple?
>
>
> Note that Larry's longer term plan is for "algebraic data types",
> including "tagged unions": https://wiki.php.net/rfc/adts Unlike
> straight-forward enum cases, these are not singletons, and each instance
> has its own associated state.

Longer term plans are irrelevant except to avoid inadvertently
shutting the door on something. This RFC is up for discussion, and
will be up for voting, in isolation. It has to be able to stand on its
own.

> 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] [RFC] Enumerations

[Paul Crovella]

On Fri, Dec 4, 2020 at 7:00 PM Larry Garfield  wrote:
>
>
> 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

Thank you for updating the RFC.

> enum cases have no state

Unless there's a bit left out from this RFC this is not completely
true, you've just limited them to annoying ways of working with data,
e.g. static variables.

> static methods on cases, which without data are exactly the same as normal 
> methods

This is an argument against instance methods, which you kept, rather
than static methods, which you didn't. How is this division anything
but arbitrary?

> Constructors - Not relevant without data/state.
> Destructors - Not relevant without data/state.

This doesn't explain the need to remove them. What problem do they cause?

> Enum/Case constants - Not necessary as methods fulfill the same use case.

How is this specific to enums? Why is it necessary to add this
inconsistency to the language in this RFC? What happens to constants
inherited from interfaces?

> Enum/Case properties - Not necessary as methods fulfill the same use case, 
> plus we want to avoid state.
> Dynamic properties - Avoid state. Plus, they're a bad idea on classes anyway.
> Magic methods except for those specifically listed below - Most of the 
> excluded ones involve state.

Again, what is it particular to enums that necessitates adding these
inconsistencies to the language? I get that *you* want to avoid state,
but how is that an enum thing rather than a you thing? What happens to
properties gained from traits?

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

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

[Paul Crovella]

On Tue, Dec 1, 2020 at 10:23 AM G. P. B.  wrote:
>
> On Tue, 1 Dec 2020 at 18:07, Paul Crovella  wrote:
>>
>> On Tue, Dec 1, 2020 at 9:43 AM Christoph M. Becker  wrote:
>> >
>> > On 01.12.2020 at 18:35, Aimeos | Norbert Sendetzky wrote:
>> >
>> > > Am 01.12.20 um 18:24 schrieb Christoph M. Becker:
>> > >>
>> > >>> In PHP 7, this returns FALSE:
>> > >>>
>> > >>> php -r 'var_dump(is_file("ab\0c"));'
>> > >>>
>> > >>> In PHP 8, the same code throws a ValueException. Problem is now that
>> > >>> it's not possible to check upfront if the passed argument is a valid
>> > >>> path to avoid the exception being thrown.
>> > >>
>> > >> This is only about the NUL byte in the filename.  You can easily check
>> > >> for that yourself. :)
>> > >
>> > > There may be other checks that will throw a ValueException. I'm not sure
>> > > how it's implemented in detail because the filestat.c file doesn't
>> > > thrown an exception at all:
>> >
>> > The exception is thrown from inside the parameter parsing routines
>> > (zend_parse_parameters() and friends).  Internal function differenciate
>> > between string and path, whereas the latter is an arbitrary string which
>> > does not contain NUL bytes.
>> >
>> > It would likely make sense to document that.  OTOH, it's probably a good
>> > idea to check (almost) all user input for NUL bytes.
>>
>> Would it not make more sense for something like is_file to have
>> obvious sane behavior and simply return false itself? I don't
>> understand the resistance to making it more difficult for a developer
>> to screw something up.
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
> So why having is_file()/is_dir() throw a warning for the past 8 years
> (since PHP 5.4) a non-issue? Because by that logic it shouldn't
> have been emitting warnings either.

That's correct, it shouldn't have.

> Would it have been fine if this would have been a TypeError as it was
> originally intended?

No, I imagine it would've been fixed sooner.

> Is a warning fine because null bytes indicate a potential attack as in no sane
> context should null bytes be passed around?

Null bytes come from many places and do not necessarily indicate an
"attack." There's plenty of UTF-16 in the world, for example, that's
got oodles of them.

> I don't personally *care* that it throws a ValueError, but why is this issue 
> only
> brought up *now* when it should have been shouting for 8 years

Because it didn't break userland code for 8 years. A ValueError is a
much louder thing - that's the whole point of it in fact. It shouldn't
be a surprise that it comes up now.

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

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

[Paul Crovella]

On Tue, Dec 1, 2020 at 9:43 AM Christoph M. Becker  wrote:
>
> On 01.12.2020 at 18:35, Aimeos | Norbert Sendetzky wrote:
>
> > Am 01.12.20 um 18:24 schrieb Christoph M. Becker:
> >>
> >>> In PHP 7, this returns FALSE:
> >>>
> >>> php -r 'var_dump(is_file("ab\0c"));'
> >>>
> >>> In PHP 8, the same code throws a ValueException. Problem is now that
> >>> it's not possible to check upfront if the passed argument is a valid
> >>> path to avoid the exception being thrown.
> >>
> >> This is only about the NUL byte in the filename.  You can easily check
> >> for that yourself. :)
> >
> > There may be other checks that will throw a ValueException. I'm not sure
> > how it's implemented in detail because the filestat.c file doesn't
> > thrown an exception at all:
>
> The exception is thrown from inside the parameter parsing routines
> (zend_parse_parameters() and friends).  Internal function differenciate
> between string and path, whereas the latter is an arbitrary string which
> does not contain NUL bytes.
>
> It would likely make sense to document that.  OTOH, it's probably a good
> idea to check (almost) all user input for NUL bytes.

Would it not make more sense for something like is_file to have
obvious sane behavior and simply return false itself? I don't
understand the resistance to making it more difficult for a developer
to screw something up.

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

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

[Paul Crovella]

On Tue, Dec 1, 2020 at 9:48 AM G. P. B.  wrote:
>
>
> On Tue, 1 Dec 2020 at 17:46, G. P. B.  wrote:
>>
>> On Tue, 1 Dec 2020 at 17:45, Paul Crovella  wrote:
>>>
>>> On Tue, Dec 1, 2020 at 9:25 AM Christoph M. Becker  
>>> wrote:
>>> >
>>> > On 01.12.2020 at 18:18, Aimeos | Norbert Sendetzky wrote:
>>> >
>>> > > PHP 8 is stricter in checking input data then PHP 7. This is good but
>>> > > has some side effects for is_file(), is_dir() and similar functions when
>>> > > invalid paths are passed for checking.
>>> > >
>>> > > In PHP 7, this returns FALSE:
>>> > >
>>> > > php -r 'var_dump(is_file("ab\0c"));'
>>> > >
>>> > > In PHP 8, the same code throws a ValueException. Problem is now that
>>> > > it's not possible to check upfront if the passed argument is a valid
>>> > > path to avoid the exception being thrown.
>>> >
>>> > This is only about the NUL byte in the filename.  You can easily check
>>> > for that yourself. :)
>>> >
>>> > Regards,
>>> > Christoph
>>>
>>> Or is_file could check for it, handle it gracefully, and be a safe
>>> function to call without worrying about this undocumented edge case.
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: https://www.php.net/unsub.php
>>>
>>
>
> Apologize my email client sent by mistake:
> But this has always generated a warning see:
> https://3v4l.org/7E2mv
>
> So this is not new behaviour.
>
> George P. Banyard

The result is in fact new. An uncaught ValueError isn't a warning.

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

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

[Paul Crovella]

On Tue, Dec 1, 2020 at 9:25 AM Christoph M. Becker  wrote:
>
> On 01.12.2020 at 18:18, Aimeos | Norbert Sendetzky wrote:
>
> > PHP 8 is stricter in checking input data then PHP 7. This is good but
> > has some side effects for is_file(), is_dir() and similar functions when
> > invalid paths are passed for checking.
> >
> > In PHP 7, this returns FALSE:
> >
> > php -r 'var_dump(is_file("ab\0c"));'
> >
> > In PHP 8, the same code throws a ValueException. Problem is now that
> > it's not possible to check upfront if the passed argument is a valid
> > path to avoid the exception being thrown.
>
> This is only about the NUL byte in the filename.  You can easily check
> for that yourself. :)
>
> Regards,
> Christoph

Or is_file could check for it, handle it gracefully, and be a safe
function to call without worrying about this undocumented edge case.

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

Re: [PHP-DEV] Community vote on RFCs

[Paul Crovella]

On Wed, Aug 19, 2020 at 4:19 PM Benjamin Morel  wrote:
>>
>> You're asking for useless, no-effort feedback in the form of votes
>> from people who have no actual involvement in the ongoing development
>> or maintenance of the project, so that's what I gave you.
>
>
> I'm surprised by these strong feelings. As a contributor and maintainer of 
> several open source projects, I'm always influenced by the number of thumbs 
> up/down feedback a message receives when reading discussions on GitHub, 
> whether they are from members/contributors of the project, or from seemingly 
> strangers. Of course, I'll often check who the feedback is coming from, and 
> this influences me as well.
>
> I feel like this kind of feedback on the RFCs would be valuable to people who 
> have a right to vote, especially if there was a way to extract specifically 
> the feedback from open source project leads or heavy contributors.
>
> But you may disagree, of course.
>
> - Benjamin

Would you have asked me to justify my position were it a "+1" instead?
Would you have still referred to it as pollution? I'm betting probably
not. This isn't a shot at you personally, questioning and criticizing
disagreement while accepting agreement without challenge is the
default thing people do - and it's part of why the polls you're after
have so little value as a feedback mechanism. If they agree with you
great - you've got a cudgel to use against those who disagree. If they
disagree with you then who cares - the poll itself was flawed
(wording, selection bias, etc.) and can be discounted out of hand as
there was no actual feedback to address. Heck, if you do it right you
can even pick and choose the votes you want based on merit badges (or
whatever other bar finds you agreement) then get on with derailing
substantive discussion to talk about the poll.

The absolute least useful thing someone can do is vote in a
non-binding poll then sit on their hands expecting it to matter. It's
100% noise. You might as well spend your day signing petitions on
facebook.

In addition the premise for your proposal is flawed and somewhat
insulting - the community already has a vote on every RFC. Lots of
them, in fact. All of them. Every single vote comes from a member of
the PHP community. And practically everyone, with voting privilege or
without, can meaningfully participate by joining the discussion. "The
community" isn't limited to people on reddit or your favorite OSS
clique and there's nothing stopping anyone from having a voice.

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

Re: [PHP-DEV] Community vote on RFCs

[Paul Crovella]

On Wed, Aug 19, 2020 at 3:35 PM Benjamin Morel  wrote:
>
> Hi Paul!
>
> I'm writing off list to avoid polluting the thread too much.

I'm writing on list because it's weird that you call this pollution.

> Could you please care to explain your negative reaction to this proposal?
>
> Kind regards,
> Benjamin

You're asking for useless, no-effort feedback in the form of votes
from people who have no actual involvement in the ongoing development
or maintenance of the project, so that's what I gave you. That you
felt compelled to ask me about it highlights this significant
shortcoming of the proposal.

> On Thu, 20 Aug 2020 at 00:27, Paul Crovella  wrote:
>>
>> -1
>>
>> On Wed, Aug 19, 2020 at 2:28 PM Benjamin Morel  
>> wrote:
>> >
>> > Hi internals,
>> >
>> > The heated debate about attribute syntax made me think once again that it
>> > would be valuable to get feedback in the form of votes from the community,
>> > not just from core developers, on RFCs under discussion.
>> >
>> > Understandably, the RFC voting process needs to be restricted to carefully
>> > selected people, mostly core developers. But the fact is, this process is a
>> > bit elitist, and fails to represent the community as a whole. A recent
>> > thread <https://externals.io/message/111552> showed that even very active
>> > contributors to OSS are unlikely to ever get a vote.
>> >
>> > A project being nothing without its users, it would be nice to know whether
>> > an important change will make them happy or not.
>> >
>> > Therefore, I have in mind to develop (time permitting) an experimental
>> > tool, external to the PHP wiki, that would replicate the voting options of
>> > each RFC, but would allow everyone with a GitHub account to vote on the
>> > same options as the original RFC. While the vote results would not directly
>> > affect the wiki's vote results, I guess that this community feedback could
>> > be taken into consideration by wiki voters and help them make an informed
>> > decision.
>> >
>> > To be useful, a link to the community voting site would need to be present
>> > in each RFC, ideally some time before the actual voting starts on the wiki.
>> >
>> > If popular enough, this tool could offer some analysis capabilities, such
>> > as "what's the vote results from people having at least 100 commits to the
>> > top 1000 packagist projects in the last year?" to help filter out the 
>> > noise.
>> >
>> > Thoughts?
>> >
>> > Kind regards,
>> > Benjamin

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

Re: [PHP-DEV] Community vote on RFCs

[Paul Crovella]

-1

On Wed, Aug 19, 2020 at 2:28 PM Benjamin Morel  wrote:
>
> Hi internals,
>
> The heated debate about attribute syntax made me think once again that it
> would be valuable to get feedback in the form of votes from the community,
> not just from core developers, on RFCs under discussion.
>
> Understandably, the RFC voting process needs to be restricted to carefully
> selected people, mostly core developers. But the fact is, this process is a
> bit elitist, and fails to represent the community as a whole. A recent
> thread  showed that even very active
> contributors to OSS are unlikely to ever get a vote.
>
> A project being nothing without its users, it would be nice to know whether
> an important change will make them happy or not.
>
> Therefore, I have in mind to develop (time permitting) an experimental
> tool, external to the PHP wiki, that would replicate the voting options of
> each RFC, but would allow everyone with a GitHub account to vote on the
> same options as the original RFC. While the vote results would not directly
> affect the wiki's vote results, I guess that this community feedback could
> be taken into consideration by wiki voters and help them make an informed
> decision.
>
> To be useful, a link to the community voting site would need to be present
> in each RFC, ideally some time before the actual voting starts on the wiki.
>
> If popular enough, this tool could offer some analysis capabilities, such
> as "what's the vote results from people having at least 100 commits to the
> top 1000 packagist projects in the last year?" to help filter out the noise.
>
> Thoughts?
>
> Kind regards,
> Benjamin

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

[PHP-DEV] Wiki RFC karma request

[Paul Crovella]

I'd like to do some work on a Partial Function Application RFC. Could
someone grant the wiki user pcrov the necessary karma?

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