[PHP-DEV] Re: [8.1] Release Manager Voting Opens

[Ben Ramsey]

> On Apr 26, 2021, at 14:47, Sara Golemon  wrote:
> 
> On Mon, Apr 12, 2021 at 2:40 PM Sara Golemon  wrote:
> Please take your newly reset authentication credentials over to 
> https://wiki.php.net/todo/php81 and place your ranked votes.
> 
> 
> The voting for PHP 8.1 Release Managers has now closed.
> 
> In the first round, both Ben Ramsey and Patrick Allaert handily captured a 
> quota of votes to secure seats meaning that 2nd and further rounds do not 
> need to be considered and we have our results.
> 
> The Veteran RM for 8.1 will be Joe Watkins.
> The Rookie RMs for 8.1 will be Ben Ramsey and Patrick Allaert.
> 
> Congratulations to Joe, Ben, and Patrick, and a big thank you to all who 
> volunteered to step up and assist with this essential role.
> 
> Please refer to 
> https://github.com/php/php-src/blob/master/docs/release-process.md#new-release-manager-checklist
>  for tips on getting permissions and other pre-release tasks.
> And of course, reach out to the RM list and/or individual prior release 
> managers at any time for help.
> 
> -Sara


Thank you so much to everyone for entrusting me to serve as one of the release 
managers for PHP 8.1! I look forward to working with Joe and Patrick over the 
next three years.

Cheers,
Ben


signature.asc
Description: Message signed with OpenPGP

[PHP-DEV] Re: [8.1] Release Manager Voting Opens

[Sara Golemon]

On Mon, Apr 12, 2021 at 2:40 PM Sara Golemon  wrote:

> Please take your newly reset authentication credentials over to
> https://wiki.php.net/todo/php81 and place your ranked votes.
>
>
The voting for PHP 8.1 Release Managers has now closed.

In the first round, both Ben Ramsey and Patrick Allaert handily captured a
quota of votes to secure seats meaning that 2nd and further rounds do not
need to be considered and we have our results.

The Veteran RM for 8.1 will be Joe Watkins.
The Rookie RMs for 8.1 will be Ben Ramsey and Patrick Allaert.

Congratulations to Joe, Ben, and Patrick, and a big thank you to all who
volunteered to step up and assist with this essential role.

Please refer to
https://github.com/php/php-src/blob/master/docs/release-process.md#new-release-manager-checklist
for tips on getting permissions and other pre-release tasks.
And of course, reach out to the RM list and/or individual prior release
managers at any time for help.

-Sara

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

[Levi Morrison via internals]

On Sun, Apr 25, 2021 at 1:51 PM Olle Härstedt  wrote:
>
> 2021-04-25 21:25 GMT+02:00, Larry Garfield :
> > 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.
> >
> > --
> >   Larry Garfield
> >   la...@garfieldtech.com
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
>
> Nice. :) Are there any other motivating use-cases besides pipe
> operator (that are relevant for web dev)?
>
> Olle
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Yes, of course! PHP has many uses of `array_map`, `array_filter`, etc,
that take a callback as a parameter. It's hard to create good examples
on the spot, but here's an example, at least:

array_filter($array, in_array(?, $haystack, strict: true))

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

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

[Levi Morrison via internals]

> If this is indeed the scenario, would it be worth adding a syntax to
> indicate _all_ parameters can be placeholders? When a signature has
> multiple arguments, `toString(?, ?, ?, ?)` could become `toString(...?)` or
> maybe something like `toString(*)`?

At the moment, there isn't any difference in `foo(?)` and `foo(?, ?,
?, ?, ?, ?, ?, ?)`. If there is one placeholder, then it will bind (or
fix) the non-placeholder arguments and then create a closure-like with
a signature of the remaining parameters. Adding more placeholders does
not change anything, except to adjust positions:

  foo(?, $bar, ?, $baz)

In this case the two placeholders are meaningful because they adjust
which positional arguments are bound. This is the only difference in
behavior in one placeholder or more.

In an earlier version of the RFC I had `...` so you could write
`foo(...)`. Some of the RFC authors didn't like this, because it was
functionally no different and brought up "when to use ? and when to
use ..." as a question.

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

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Christian Schneider]

Am 26.04.2021 um 14:18 schrieb Ilija Tovilo :
> The point of sealed type is to fix the number of subclasses a given
> type can have, which means you can handle a value by type (as that
> list is not finite). Code that handles Optional values could look like
> this:
> 
> ```
> if ($option instanceof Option\None) {
>throw new Exception();
> }
> 
> // We now know the value is a Some
> var_dump($option->value);
> ```

I really hope that's *not* the way people will use the Maybe type

> If you suddenly provide your own version of None the code above will
> break.

... but no, it wouldn't break, as MyNone extends None, so instanceof would 
still work.

> To most people it's obvious that you can't add new cases to an
> existing enum.

The RFC does not mention data classes (at least not explicitly), it talks about 
sharing common functionality.
So I think you're somewhat moving the goal posts.
If you want to limit Enums only then I would have to reconsider, but we were 
talking about generic classes AFAIK.

> It doesn't sound sensible to add logging to a data
> class. That's something that belongs into a hook or service of some
> kind.

You're again making assumption about what's sensible for the user of a library, 
that's the mind-set I would like to avoid.

> People might also want to use sealed for behavioral classes, the use
> case here is the same as final. Final is not here to make your life
> harder. It's here to make the lives of the library maintainers easier.

First of all: Yes, I'm no fan of final either.
I've encountered enough examples where it *did* make my life harder.
And as a library writer myself I value the user experience higher than the 
library developer work because there are (hopefully) a lot more users than 
developers.

> If they have to reason about every way a method could be overridden,
> every change in the library would become more risky, require more
> thought and more frequent major version updates.

A properly designed API should be simple and stable enough to not need this 
kind of safe-guards.
Overly complicated, cathedral-style frameworks might yearn for it but I think 
it's addressing the symptoms, not the cause (-:C

> This means more work and less features for you, too.


That kind of argument reminds me of people saying that user tracking is a good 
thing because I get to see more relevant advertisement.
You're a good sales-man though, I give you that, but you haven't convinced me 
yet ;-)

- Chris

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Ilija Tovilo]

Hi Christian

On Mon, Apr 26, 2021 at 9:54 AM Christian Schneider
 wrote:
>
> Am 25.04.2021 um 05:47 schrieb Larry Garfield :
> > In practice, I think all of the use cases for sealed classes are ADT-esque. 
> >  As I noted before, combining sealed classes with Nikita's 
> > new-in-expressions RFC would allow for this (also using my short-functions 
> > RFC for this example, although that's a nice-to-have):
> >
> > sealed class Maybe permits Some, None {
>
> ...
>
> > }
> >
> > final class None extends Maybe {}
>
>
>
> This is exactly the thing I'm worried about.
>
> Say I want to add something like logging to the None type.
> Now your sealed and final classes prevent me from defining MyNone extending 
> None even though it would be 100% compatible with None. Just because *you* 
> deemed that useless or wrong.

The point of sealed type is to fix the number of subclasses a given
type can have, which means you can handle a value by type (as that
list is not finite). Code that handles Optional values could look like
this:

```
if ($option instanceof Option\None) {
throw new Exception();
}

// We now know the value is a Some
var_dump($option->value);
```

If you suddenly provide your own version of None the code above will
break. This is probably more obvious when you look at the
enum-equivalent.

```
enum Option {
case None;
case Some($value);
}
```

To most people it's obvious that you can't add new cases to an
existing enum. It doesn't sound sensible to add logging to a data
class. That's something that belongs into a hook or service of some
kind.

People might also want to use sealed for behavioral classes, the use
case here is the same as final. Final is not here to make your life
harder. It's here to make the lives of the library maintainers easier.
If they have to reason about every way a method could be overridden,
every change in the library would become more risky, require more
thought and more frequent major version updates. This means more work
and less features for you, too.

Ilija

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

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[David Gebler]

Yes I agree Chris, this is the same kind of argument I am making.

> Note that the *exact* same argument could be made for typing parameters.
I can document via a docblock that I expect a given parameter to be a
string, or a Request object, or whatever.  "There is little to no benefit
in expressing that through a new language construct rather than through
existing constructs and design patterns."

Yes and no. There is a critical difference between type checking and sealed
- type checking can actually prevent and catch bugs in the form of
objective logical errors (e.g. $total = getSum(1, 2, "not a number"))
before they occur, whereas sealed can only prevent things you did not
intend or foresee, without knowing anything about how I am using some code;
there is no bug or logical error which the use of sealed will prevent *in
and of itself*.

> Except there very much is a benefit, for making the intent of code
clearer and for allowing the engine to syntactically make certain invalid
states impossible.

This is not runtime benefit, it is runtime overhead. PHP cannot generate a
better opcode sequence for knowing a class is sealed. In terms of
implementation, the only thing it can do is scream "Hey! The author of this
class didn't intend for you to use it this way!" - your IDE can do that
from an attribute.

And although I would say the claim no one will ever have a legitimate &
good reason to extend some class and be able to do so in a way which does
not violate whatever protections against invalid state you had in mind is a
very bold prediction which is rarely borne out by reality - my objection
here is not about people marking classes as sealed, it's that we don't need
a new language construct and keyword to achieve the only benefit it
delivers (declaration of intent to users and IDE). If PHP reasoned about
classes in the same way compiled, statically typed languages do and
therefore derived some tangible compile-time benefit from a sealed
construct, I would be in favour of it.


On Mon, 26 Apr 2021, 08:54 Christian Schneider, 
wrote:

> Am 25.04.2021 um 05:47 schrieb Larry Garfield :
> > In practice, I think all of the use cases for sealed classes are
> ADT-esque.  As I noted before, combining sealed classes with Nikita's
> new-in-expressions RFC would allow for this (also using my short-functions
> RFC for this example, although that's a nice-to-have):
> >
> > sealed class Maybe permits Some, None {
>
> ...
>
> > }
> >
> > final class None extends Maybe {}
>
>
>
> This is exactly the thing I'm worried about.
>
> Say I want to add something like logging to the None type.
> Now your sealed and final classes prevent me from defining MyNone
> extending None even though it would be 100% compatible with None. Just
> because *you* deemed that useless or wrong.
>
> I've encountered situations like this and came to the conclusion that
> while this makes sense for languages like Haskell - where the whole idea is
> to be able to reason about a complex type system - it is an anti-pattern
> for other languages like PHP.
>
> Referring to another post, not yours: People, please don't use Java as a
> reason to add something to PHP, Java is the king of anti-patterns ;-)
>
> - Chris
>
>

[PHP-DEV] log_errors_max_len ini setting

[Nikita Popov]

Hi internals,

In PHP 8.0, as part of some refactoring of the error handling system, I've
accidentally dropped support for the log_errors_max_len ini setting. The
setting still exists, but doesn't do anything.

https://github.com/php/php-src/pull/6838 was opened to drop it entirely,
rather than reintroducing support. The sentiment seems to be that this
setting is more harmful than useful.

I'm bringing this to the attention of the mailing list to check whether
there are any opposing opinions...

Regards,
Nikita

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

[Lynn]

On Sun, Apr 25, 2021 at 9:26 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.
>
> --
>   Larry Garfield
>   la...@garfieldtech.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Heya, this is an interesting feature!

The way I understand it, it adds the ability to turn a call to an object
method into a callable?
```php
class CategorizedThings {
private array $theThings = [];
public function addOneThing(mixed $thing, string $category): void {
$this->theThings[$category] = $thing;
}
}

$things = new CategorizedThings();
$adder = $things->addOneThing(?, 'a category');

foreach ($repository->findAll() as $aThing) {
$adder($aThing);
}

// which would be the same as:

$things = new CategorizedThings();
$adder = function (mixed $aThing) use ($things) {
$things->addOneThing($aThing, 'a category');
}

foreach ($repository->findAll() as $aThing) {
$adder($aThing);
}
```

I assume the following would also be possible?
```php
class Something {
public static function toString(mixed $v): string {
return (string) $v;
}
}

function toString(mixed $v) : string {
return (string) $v;
}

array_map(Something::toString(?), [1, 2, 3]);
array_map(toString(?), [1, 2, 3]);
// instead of
array_map([Something::class, 'toString'], [1, 2, 3])
array_map('toString', [1, 2, 3]);
```

If this is indeed the scenario, would it be worth adding a syntax to
indicate _all_ parameters can be placeholders? When a signature has
multiple arguments, `toString(?, ?, ?, ?)` could become `toString(...?)` or
maybe something like `toString(*)`?

Re: [PHP-DEV] RFC: mysqli::in_transaction

[Gabriel O]

What about OCI8 driver? That’s also included in core. 

Also a sidermark: SQLSrv and IBMDB2 are not part of core, but situation should 
be checked in those as well, since they are supported in DBA tooL


 
Powered by Mailbutler 
,
 the email extension that does it all

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Christian Schneider]

Am 25.04.2021 um 05:47 schrieb Larry Garfield :
> In practice, I think all of the use cases for sealed classes are ADT-esque.  
> As I noted before, combining sealed classes with Nikita's new-in-expressions 
> RFC would allow for this (also using my short-functions RFC for this example, 
> although that's a nice-to-have):
> 
> sealed class Maybe permits Some, None {

...

> }
> 
> final class None extends Maybe {}



This is exactly the thing I'm worried about.

Say I want to add something like logging to the None type.
Now your sealed and final classes prevent me from defining MyNone extending 
None even though it would be 100% compatible with None. Just because *you* 
deemed that useless or wrong.

I've encountered situations like this and came to the conclusion that while 
this makes sense for languages like Haskell - where the whole idea is to be 
able to reason about a complex type system - it is an anti-pattern for other 
languages like PHP.

Referring to another post, not yours: People, please don't use Java as a reason 
to add something to PHP, Java is the king of anti-patterns ;-)

- Chris

[PHP-DEV] RFC: mysqli::in_transaction

[Grégoire PARIS]

Hi, Grégoire Paris here!

I'm a maintainer on Doctrine projects and today, I'd like to talk to you
about something we would like to propose.

We have found that PDO has a method called PDO::inTransaction() that we
would like to mimic in the API of doctrine/dbal, a database abstraction
layer many of you may already know. We would like to implement this in
driver abstraction classes, so that we can call the new method from our
existing Connection::isTransactionActive() method.

Connection::isTransactionActive() currently relies on a counter, but as
you may know, this is not foolproof because of how some RDBMS like MySQL
will implicitly commit transactions when DDL is involved. In such cases,
the method will return true when it should really return false.



Our problem is, we are missing an API similar to PDO::inTransaction()
for the mysqli driver.


We would like to contribute that API and Sergei Morozov already worked
on a patch. It is available at 
https://github.com/php/php-src/compare/PHP-8.0...morozov:mysqli-in-transaction 
,

and can be tested as follows:

---
in_transaction());
$conn->begin_transaction();
var_dump($conn->in_transaction());
$conn->rollback();
var_dump($conn->in_transaction());
echo PHP_EOL;

echo 'Testing DDL:', PHP_EOL;
mysqli_query($conn, 'DROP TABLE IF EXISTS foo');
mysqli_begin_transaction($conn);
var_dump(mysqli_in_transaction($conn));
mysqli_query($conn, 'CREATE TABLE foo(id INT)');
var_dump(mysqli_in_transaction($conn));
echo PHP_EOL;
---

> Testing commit, procedural interface:
> bool(false)
> bool(true)
> bool(false)
>
> Testing rollback, OO interface:
> bool(false)
> bool(true)
> bool(false)
>
> Testing DDL:
> bool(true)
> bool(false)

Would it be OK for us to go ahead and contribute this?

The DBAL RFC can be found at https://github.com/doctrine/dbal/issues/4616

Best regards,

--
Grégoire Paris

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

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Olle Härstedt]

2021-04-26 9:37 GMT+02:00, Pierre :
> Le 26/04/2021 à 09:35, Olle Härstedt a écrit :
>> 2021-04-26 9:22 GMT+02:00, Pierre :
>>> Le 25/04/2021 à 21:22, Larry Garfield a écrit :
 Stitching together 2 replies to minimize thread noise...

 On Sun, Apr 25, 2021, at 11:58 AM, Michał Marcin Brzuchalski wrote:

> Speaking of Attributes I prefer not to use an Attribute for any
> particular
> language feature which expects input arguments to be a valid class or
> interface name for two reasons: first because there is no effective
> way
> to
> restrict input string to be a valid class or interface name and second
> that
> it'd require passing strings which means in most cases passing class
> or
> interface name with magic ::class constant read.
>
> Cheers,
> Michał Marcin Brzuchalski
 That's actually a pretty solid argument against attributes here,
 honestly.
   Consider me convinced, and now in favor of "final class Foo permits
 Bar,
 Baz". :-)

>>> Yes, even though I was the first mail suggesting it in the beginning,
>>> this is a solid argument which actually do change my mind.
>>>
>>> In the end, I like the `class Foo permis Bar, Baz` syntax, with a single
>>> keyword added.
>>>
>>> --
>>>
>>> Pierre
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: https://www.php.net/unsub.php
>>>
>>>
>> Is there actually a bug that this functionality can/could prevent? I
>> get that Maybe and Result types should be closed, but what are the
>> risk of software defects if someone abuses that fact (locally)?
>
> I don't know if you replied to the right mail, I should have specified I
> was talking about using an attribute versus adding a new keyword to the
> language.

Sorry, I was replying to the thread in general, not your reply
specifically. ^^ Maybe I should have replied to the top mail instead,
sorry.

Olle

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

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

[Olle Härstedt]

2021-04-26 0:19 GMT+02:00, Larry Garfield :
> On Sun, Apr 25, 2021, at 4:34 PM, Olle Härstedt wrote:
>
>
>> By the way, for pipe operators to be really useful, it should probably
>> be possible to combine with middleware.
>>
>> Olle
>
> Pipes are their own RFC I plan to bring back up after this one gets closer
> to a vote or passes, as they complement each other nicely.  I'm not sure
> what you mean here, though.  Pipes *are* a middleware style, just a
> different approach than the deeply nested call stack that is typical today.
>
> --Larry Garfield

I was thinking of middleware as defined in PSR (since that's what
middleware frameworks are built on). Would be nice with a connection
there.

Olle

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

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Pierre]

Le 26/04/2021 à 09:35, Olle Härstedt a écrit :

2021-04-26 9:22 GMT+02:00, Pierre :

Le 25/04/2021 à 21:22, Larry Garfield a écrit :

Stitching together 2 replies to minimize thread noise...

On Sun, Apr 25, 2021, at 11:58 AM, Michał Marcin Brzuchalski wrote:


Speaking of Attributes I prefer not to use an Attribute for any
particular
language feature which expects input arguments to be a valid class or
interface name for two reasons: first because there is no effective way
to
restrict input string to be a valid class or interface name and second
that
it'd require passing strings which means in most cases passing class or
interface name with magic ::class constant read.

Cheers,
Michał Marcin Brzuchalski

That's actually a pretty solid argument against attributes here, honestly.
  Consider me convinced, and now in favor of "final class Foo permits Bar,
Baz". :-)


Yes, even though I was the first mail suggesting it in the beginning,
this is a solid argument which actually do change my mind.

In the end, I like the `class Foo permis Bar, Baz` syntax, with a single
keyword added.

--

Pierre

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



Is there actually a bug that this functionality can/could prevent? I
get that Maybe and Result types should be closed, but what are the
risk of software defects if someone abuses that fact (locally)?


I don't know if you replied to the right mail, I should have specified I 
was talking about using an attribute versus adding a new keyword to the 
language.


--

Pierre

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

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Olle Härstedt]

2021-04-26 9:22 GMT+02:00, Pierre :
> Le 25/04/2021 à 21:22, Larry Garfield a écrit :
>> Stitching together 2 replies to minimize thread noise...
>>
>> On Sun, Apr 25, 2021, at 11:58 AM, Michał Marcin Brzuchalski wrote:
>>
>>> Speaking of Attributes I prefer not to use an Attribute for any
>>> particular
>>> language feature which expects input arguments to be a valid class or
>>> interface name for two reasons: first because there is no effective way
>>> to
>>> restrict input string to be a valid class or interface name and second
>>> that
>>> it'd require passing strings which means in most cases passing class or
>>> interface name with magic ::class constant read.
>>>
>>> Cheers,
>>> Michał Marcin Brzuchalski
>> That's actually a pretty solid argument against attributes here, honestly.
>>  Consider me convinced, and now in favor of "final class Foo permits Bar,
>> Baz". :-)
>>
> Yes, even though I was the first mail suggesting it in the beginning,
> this is a solid argument which actually do change my mind.
>
> In the end, I like the `class Foo permis Bar, Baz` syntax, with a single
> keyword added.
>
> --
>
> Pierre
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Is there actually a bug that this functionality can/could prevent? I
get that Maybe and Result types should be closed, but what are the
risk of software defects if someone abuses that fact (locally)?

Olle

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

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Pierre]

Le 25/04/2021 à 21:22, Larry Garfield a écrit :

Stitching together 2 replies to minimize thread noise...

On Sun, Apr 25, 2021, at 11:58 AM, Michał Marcin Brzuchalski wrote:


Speaking of Attributes I prefer not to use an Attribute for any particular
language feature which expects input arguments to be a valid class or
interface name for two reasons: first because there is no effective way to
restrict input string to be a valid class or interface name and second that
it'd require passing strings which means in most cases passing class or
interface name with magic ::class constant read.

Cheers,
Michał Marcin Brzuchalski

That's actually a pretty solid argument against attributes here, honestly.  Consider me 
convinced, and now in favor of "final class Foo permits Bar, Baz". :-)

Yes, even though I was the first mail suggesting it in the beginning, 
this is a solid argument which actually do change my mind.


In the end, I like the `class Foo permis Bar, Baz` syntax, with a single 
keyword added.


--

Pierre

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