e is that folks will still
consider it as "something that doesn't exist yet" and will keep requesting
it.
Something else that is worth mentioning, I like that Collection is being
discussed as a small step as well. It's a very common use of Generics and
would be a great addition to the language if something solid comes out of
it.
--
Marco Deleu
e or document the existence of third-party PHP
projects as part of their roles in supporting the overall PHP community.
Such use does not represent endorsement of those third-party projects by
the PHP Project.*
--
Marco Deleu
Such community members would certainly opt to build
this upon Symfony, Laravel, Slim or anything more convenient than vanilla
PHP and such "unwritten" rule keeps us chained to suboptimal infrastructure.
[1] https://externals.io/message/124843#124860
--
Marco Deleu
he community.
As it has been said, it is a disservice to the PHP project to be stuck on
vanilla PHP for things that require improvements, maintainers, revamp, etc.
--
Marco Deleu
On Mon, Apr 10, 2023, 2:26 PM Larry Garfield wrote:
>
> No. Stop. This is not what Ilija said at all. It is FUD to the point of
> disinformation, and is an insult to the hundreds of people that have
> worked, mostly on their own time, to give you the most popular web language
> in the world, f
On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks
wrote:
>
>
> On Mon, 10 Apr 2023 at 21:30, Deleu wrote:
>
>> On Mon, Apr 10, 2023, 1:17 PM Pierre Joye wrote:
>>
>> > hello,
>> >
>> >
>> > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller <
On Mon, Apr 10, 2023 at 6:42 PM Arvids Godjuks
wrote:
>
>
> On Tue, 11 Apr 2023 at 00:03, Deleu wrote:
>
>>
>>
>> On Mon, Apr 10, 2023, 4:01 PM Arvids Godjuks
>> wrote:
>>
>>>
>>>
>>>
>>>> *snip to keep the email
On Mon, Apr 10, 2023 at 7:03 PM Larry
>
> Again, let's assume there is no question it will happen. The question for
> you: What process for making it happen would you consider sufficiently
> BC-friendly? What timeline? What level of pre-review? What reasonable
> process would you propose that
On Tue, Apr 11, 2023 at 5:40 AM Alex Wells wrote:
> On Tue, Apr 11, 2023 at 6:10 AM Deleu wrote:
>
>> I don't want to use those weird stuff, but I'm
>> doing the best I can to replace every single line of old code that has
>> been
>> written in an era
On Tue, Apr 11, 2023, 11:32 AM Larry Garfield
wrote:
> But the same people will still complain just as loudly whenever that is,
> because they haven't done anything about it for the past 17 years so
> they're not going to now.
>
Do you know that for a fact or should this statement be classified
7;t find it on externals.io and I was curious to know
what are the challenges there since a lot of time and effort seem to have
been put on trying to sidestep it.
--
Marco Deleu
mitation
built-in. We come out of it with 3 major wins (from my pov):
- Function autoloading
- Type Aliasing
- Never creating 3 files for 3 Enums again
If you managed to read up to here, I apologize for late confessing I know
nearly nothing about PHP internals codebase. Is this obviously wrong and am
I just hallucinating a new awesome PHP version here?
--
Marco Deleu
ppens if I pass a short-closure?
>
> takeTwo(fn ($x, $y) => $x + $y);
>
> I would be annoyed if I had to write the type info, but particularly
> the return type.
>
Sorry for the unhelpful email, but does anybody else see the irony here?
It's just too funny to not be mentioned
--
Marco Deleu
On Fri, Apr 21, 2023 at 4:10 AM Robert Landers
wrote:
> Hey Deleu,
>
> I ended up on this list in the first place because I wanted to figure
> out how to implement type aliases. I can confidently say why no one
> wants to touch it with a ten-foot pole: implementing th
tps://externals.io/message/120094#120097), the argument
against a simple "use" statement seems quite natural. I certainly don't
want to redefine "use int|float as Number" in every PHP file I work with,
so naturally we would go back to type alias definition, symbol registration
and autoloading. So I guess my final question is: what is fundamentally
different about Type Alias when compared to interfaces, classes, enums that
make this controversial?
--
Marco Deleu
ion autoloading (making it opt-in) & then you can choose to
opt-in by using a strategy that perhaps allows you to fade away the
performance impact with the Composer Static Scanner dumping mechanism.
I feel like this all sounds too good to be true/possible because if it were
easy, it would maybe have been done by now. Even if we park function
autoloading altogether (for its controversy) and focus just on type
aliases, the question remains: Why is it not possible to make Type Alias
the same way that Enum was recently introduced?
--
Marco Deleu
itory to host the PHP package code.
3- CI/CD
4- Release Management
5- Versioning Strategy
6- Package naming convention
7- Distribution strategy (single package vs multiple sub-packages)
8- PHP developers and community contributions
Anything I'm missing? Thoughts?
--
Marco Deleu
pear.php.net/package/File_Util/docs/latest/File/File_Util/File_Util.html#methodbuildPath
>
> rr
I have worked with PHP for 14 years now and I know nothing about PEAR. It
either says something about me or about PEAR.
--
Marco Deleu
On Thu, May 18, 2023 at 11:27 AM Rowan Tommins
wrote:
> On Thu, 18 May 2023 at 14:12, Deleu wrote:
>
> > > Or PEAR?
> > > Like that particular path_join() request is exactly
> > >
> >
> https://pear.php.net/package/File_Util/docs/latest/Fil
it or installing it. I imagine that
it would take many years until someone could actually build up a reputation
and a library quality until it could start being considered for adoption.
[1] https://github.com/spatie/string
[2] https://laravel.com/api/9.x/Illuminate/Support/Str.html
[3] https://symfony.com/doc/current/components/string.html
[4] https://github.com/azjezz/psl/tree/next/src/Psl/Str
--
Marco Deleu
On Thu, May 18, 2023 at 2:35 PM Rowan Tommins
wrote:
> On Thu, 18 May 2023 at 16:27, Deleu wrote:
>
> Monolog is a great example of what PHP is missing - a single library for a
> > purpose. I have never worked with any other library besides Monolog and I
> > never worked
On Thu, May 18, 2023 at 6:56 PM Rowan Tommins
wrote:
> On 18 May 2023 20:15:44 BST, Deleu wrote:
> > I meant exactly the opposite. Monolog is an example of what PHP (is
> missing
> > === doesn't have enough of). There's hardly any reason to re-release it
> &g
for interfaces. I find
the Template Pattern to be a good use case for interfacing through abstract
classes and they could benefit from abstract properties, but all of
inheritance's shortcomings are still present in abstract classes and not on
interfaces.
--
Marco Deleu
default implementation should be
> chosen? There is a proposal for resolving this in some cases which is
> modelled after Java's implementation, but it isn't implemented.
>
> Thank you for your time. I look forward to productive feedback.
>
> Levi Morrison
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Marco Deleu
>
> I still believe this information should be added to the RFC as the risk
> of adding new methods to an interface which collide with existing
> methods in implementations of that interface is very real, though I
> agree with Deleu that this BC impact is not so much of the RFC, bu
and would it behave as expected?
```
interface Interface1 {
function method1() { echo __METHOD__ . "\n"; }
}
interface Interface2 {
function method1() { echo __METHOD__ . "\n"; }
}
class Class1 implements Interface1, Interface2 {
function method1() {
$result = Interface1::method1();
Interface2::method1();
return $result;
}
}
$result = (new Class1())->method1();
```
--
Marco Deleu
ding is that although it could have been nice to not allow
these weird quirks, that ship has sailed decades ago and doing it on an
interface default implementation (even if it was possible) would just
create a major language inconsistency and it would always be best to
implement this RFC without it regardless of technical limitations.
--
Marco Deleu
p
>
>
That's wonderful news Levi! Good luck to us all on this RFC!!
--
Marco Deleu
ther
hand is extremely powerful and clear. If you're not happy with the default
implementation, just write your own, otherwise less code to write and a
better type system at the end.
--
Marco Deleu
possible to extend something
that actually is part of the domain definition. Interface Default
Implementation is an elegant solution that doesn't change the state of PHP
while still making things easier and convenient to manage.
--
Marco Deleu
On Tue, Jul 11, 2023, 7:32 PM David Gebler wrote:
> Looks - sadly to me - like this isn't going to pass. I don't have vote
> karma and if I did it wouldn't make a difference to the outcome, but it
> would be really good for those of us who can't vote on the feature to hear
> from some of the peop
On Thu, Jul 13, 2023 at 8:46 AM Brent Roose via internals <
internals@lists.php.net> wrote:
> I want to pitch in, agreeing with Larry's message here.
>
> - There are multiple real life use cases where the combo trait/interface
> could be replaced by interface default methods
> - Several modern lan
Perhaps a little too late, but I was wondering whether folks that voted NO
would reconsider in case this was made a bit more opt-in.
There could be some bikesheding around syntax but essentially the idea
would be a new RFC targeting 8.4 with the following adjustment:
interface Foo {
public fu
lectively getting Voting Karma so that we can have these
awesomeness revisited.
--
Marco Deleu
and happy testing!
>
> Regards,
> Jakub Zelenka & Eric Mann
I just want to say a big thank you for PHP 8.3. I just ran about 2000
phpunit tests with it and 0 code change was necessary.
I'm looking forward to upgrading!
--
Marco Deleu
rd within the PHP language. The door of creating of a block with
auto-capture look-and-feel much better across many different aspects of the
language, but it's always shutdown by enough long-time voters.
Overall, between the choice of creating a new syntax that "kind of
represents return statements on specific scenarios" or option 3 - do
nothing, I would prefer to do nothing until we manage to gather enough
voters to overcome the "no-auto-capture" camp.
--
Marco Deleu
On Sun, Sep 10, 2023 at 12:51 PM Rowan Tommins
wrote:
> On 10 September 2023 15:35:44 BST, Deleu wrote:
> > ... until we manage to gather enough
> >voters to overcome the "no-auto-capture" camp.
>
>
> I think that's a rather adversarial / political way t
n
JIT 2.0.
Of course this is a very basic analysis on my part which mixes my
experience in replacing PHP running-systems with new rewrites and it's much
more comfortable to me to have a fallback mechanism in place which may or
may not be entirely relevant here.
--
Marco Deleu
line arrow
function).
Long story short, Fibers being something "incomplete" from a userland
perspective is a feature, not a bug. Look at it as the simplest, smallest
(while still being feature-complete) way to expose the ability to write
async code in PHP while Swoole is almost an ecosystem on its own.
--
Marco Deleu
irst($array) ?? throw new Exception();
>
This function signature can be accomplished by userland once we have
`array_key_first()` and `array_first()`. It's much better to keep
`array_first()` as simple as possible and let everyone build their own
approach to go about it since we have so many approaches.
--
Marco Deleu
On Wed, Oct 18, 2023 at 4:31 AM Robert Landers
wrote:
> On Wed, Oct 18, 2023 at 5:26 AM Deleu wrote:
> >
> > On Tue, Oct 17, 2023 at 3:43 PM Brandon Jackson
> > wrote:
> >
> > > > There is also a technique to make the return value `[$key => $value
On Wed, Oct 18, 2023 at 9:29 AM Robert Landers
wrote:
> On Wed, Oct 18, 2023 at 1:43 PM Deleu wrote:
> >
> >
> >
> > On Wed, Oct 18, 2023 at 4:31 AM Robert Landers
> wrote:
> >>
> >> On Wed, Oct 18, 2023 at 5:26 AM Deleu wrote:
> >>
ided by
core.
* If naming is an issue to you, I'd also be fine with
`array_value_first()`.
--
Marco Deleu
problem of Fibers do not
mean anything to you as the developers providing the library/functionality
will have to find ways to avoid exposing an API with broken behavior.
Whether today or 1 year from now 100% of PHP code will be taking advantage
of Fibers or not is irrelevant to this discussion.
--
Marco Deleu
for Generics. I've been
working with Typescript lately and I see generics only being useful for
library code and even then when I end up writing some valid Generics stuff,
Typescript verbosity becomes so bloated that it invalidates the added-value
of the functionality.
I truly can't understand how Generics is the most requested PHP feature so
I will just assume I will have to live with it one day, but mixing it with
Attributes Syntax seems to be a recipe to make it as bad (or worse) than
the experience of using Generics in Typescript.
--
Marco Deleu
alue() in the future if needed.
In fact, I encourage you to propose an RFC for `array_first_key_value()` as
a solution for the problem you're raising.
--
Marco Deleu
voters think it's best to overload `~=` instead of `==`, I
think we bite the bullet and deal with the consequences. Even though I have
every reason not to want `~=`, PHP deserves method overloading unless folks
can show facts as to why nearly every other major programming language is
wrong or why they can have it and we can't.
--
Marco Deleu
ues and they have
`key` when working with array keys. With that, array_first() cannot be
"consistent" with array_key_first() without being inconsistent with dozens
of PHP array functions.
Larry's comment is enough to close down the discussion on the function name
as there's no room for anything other than `array_first()` in my opinion.
--
Marco Deleu
s line of thought has any merit, a better question would be whether
Type Alias needs a separate autoload function from class/interfaces or a
single autoload is better. I think that's the kind of discussion that would
help Composer/PSR to decide how to expand and improve the PHP Ecosystem to
include handling of Type Aliases.
--
Marco Deleu
an ad-hoc self-contained Annotation that simply goes
through the class and automatically set everything to null before the
engine does its thing. In a way, it could still be a BC-break no matter
what - 2 different behaviors of the language, but I'm thinking that such
attribute could make things behave as-is 99% of the time and allow legacy
systems to still breathe.
--
Marco Deleu
ngs subject to change in such a long timeline. Maybe
the current technical debt or the current suite of tests make this feature
less of a burden than it used to be or maybe our understanding of the value
of such a feature has changed in the course of 9 years.
--
Marco Deleu
there any
controversial thoughts around it?
Thanks!
--
Marco Deleu
rsions), a migration path assumes users will use of
Rector, Static Analysers and PHPUnit and the old engine keeps the BC
promise in order to allow old software to keep running, but is expected to
degrade in performance and to only support new stuff if it has no added
burden to internals.
When such assumptions are made about userland, the concept of what's an
acceptable BC break should be skewed in favor of helping PHP Internals.
--
Marco Deleu
face) of that object and the __construct() is a special method
that is not assumed to be part of that blueprint because it's not
reasonable to do `$object->__construct();` after receiving an object. As
such, a constructor cannot break LSP because the constructor is not part of
the object's API from a "receptor" point of view.
I don't have a vote so take my opinion with a bucket of salt, but if I
could I would definitely vote against such RFC.
--
Marco Deleu
, I think PHP has the best of both worlds. We get little
helpers to accommodate how OOP looks like in a dynamic script language
(i.e. new static()) and we have a fully functioning LSP that allows you to
take advantage of it however you see fit. The Queue example goes to show
why having a constructor as part of the public API of a class hierarchy
would be extremely bad, but PHP is nice enough to let you opt-in to it if
you have reasons to force a class hierarchy to have a single dependency
signature.
--
Marco Deleu
abase/21/admin/distributed-transactions-concepts.html#GUID-8152084F-4760-4B89-A91C-9A84F81C23D1
> )
> all support it.
>
>
> --
> Best regards,
> Bruce Weirdan mailto:
> weir...@gmail.com
>
Having MySQL XA Transactions exposed via PDO methods through a simplified
user experience would be amazing.
--
Marco Deleu
rn PHP
Engine Namespace (worker), Purpose Namespace (_http, _websocket, etc) and
Variation Namespace (_classic, _psr7, _raw).
For me personally one awesome last step would make this a PHP Class instead
of procedural functions. That would be even better because we could use the
Class namespace itself to version it and provide future changes without
breaking what's been introduced already.
--
Marco Deleu
}
}
```
It feels quite a natural syntax for PHP and from someone oblivious to the
internal work, it appears to be a slight marginal change to the existing
RFC. Given the extensive work of this RFC, it seems pretty obvious that
this syntax will not work, I just don't know why.
--
Marco Deleu
ic string $name {
> set {
> return usfirst($value);
> }
> }
> ```
> Where the value returned in the set is what the property will be set to?
>
The answer to this question is best described on the RFC FAQ:
https://wiki.php.net/rfc/property-hooks#why_do_set_hooks_not_return_the_value_to_set
--
Marco Deleu
he proposal seems far
simpler and reaches 100% of PHP projects as opposed to the ones that either
opt to use psalm or opt to use azjezz/psl.
--
Marco Deleu
ever, because hashing is complex, this will be
> postponed to a separate RFC.
>
> One known gotcha is that we cannot trivially enforce placement of
> `modfying` on methods without a performance hit. It is the
> responsibility of the user to correctly mark such methods.
>
> Here's a fully functional PoC, excluding JIT:
> https://github.com/php/php-src/pull/13800
>
> Let me know what you think. I will start working on an RFC draft once
> work on property hooks concludes.
>
> Ilija
>
Looking forward to this!!!
--
Marco Deleu
ecessary (requiring another RFC vote).
Making it mixed on version 1 means that support for the mixture of them can
never be undone.
--
Marco Deleu
property"
>
> new MyClass()->method(),// string(6) "method"
>
> new MyClass()(),// string(8) "__invoke"
>
> );
>
> ```
>
>
> For more details see the RFC:
> https://wiki.php.net/rfc/new_without_parentheses
>
> Implementation: https://github.com/php/php-src/pull/13029
>
>
> --
>
> Best regards, Valentin
>
Yes, please!
--
Marco Deleu
e a great solution to get us out
of the nightmare of `require` and `import` on top of PHP files. But more
than once I have had the desire to declare a couple of interfaces in a
single file, or a handful of Enums, etc. It seems like PHP Modules could
also address the issue with function autoloading and package-level
visibility. I like the idea but I'm a bit skeptical until we have some
buy-in from someone that could actually get this implemented.
--
Marco Deleu
t;: {
"php": "^8.2"
},
"php-modules": {
"@packages": "./packages",
"@utilities": "./tools/utilities"
}
}
```
Then whenever there's a `import Foo from '@packages/Foo.php'`, the notation
`@packages` would be replaced by the packages folder. This is equivalent to
Vite resolve.alias
https://vitejs.dev/config/shared-options.html#resolve-alias
--
Marco Deleu
s come to PHP's issue tracker
to complain, the answer is plain and simple: that behavior was not approved
by PHP's RFC process, which is the only way to get a behavior change
introduced into the language. Realistically, it's highly questionable that
such hypothetical users would even show up.
--
Marco Deleu
onsuming token_get_all() in favor of protecting
imaginary PHP users that would have been adventurous enough to make use of
comments between `yield` and `from`."
--
Marco Deleu
similar concept
exists in the Javascript ecosystem with hoisting import statements and
mocking modules, but if you don't understand the system and are unaware
that order of import execution will matter on whether the mock succeeds or
not plays a huge role in making it a cumbersome and awkward system.
Regardless, it's not possible for functions as users don't control function
autoloader.
--
Marco Deleu
rue for string values
and for consistency the `numeric` type-hint would behave similarly.
Thoughts?
--
Marco Aurélio Deleu
> Hi Marco,
>
> On Tue, 2 Jun 2020 at 16:10, Deleu wrote:
>
> >
> > The primary intent would be to safely pass around input that usually
> comes
> > from HTTP, CI or Database. Whenever interacting with these data
> providers,
> > string is a common format. `is
he cost specially when looked
at it from the `is_numeric` perspective, which is an existing behavior.
On Wed, Jun 3, 2020 at 12:26 PM Nikita Popov wrote:
> On Tue, Jun 2, 2020 at 5:10 PM Deleu wrote:
>
>> Hello Internals,
>>
>> I'd like to know what would be people
What if Nikita changes the RFC to target PHP 8.1 but proceed with voting
now? If voting passes, the RFC will be pending implementation and the
"news" will start to spread. Brandt will write about it in his blog, Reddit
will have a post about it, etc. and the community will start to spread the
infor
+1.
While I agree that the status of the php project makes the discussion much
more productive by having an actionable process in place, I do sympathize
with the original author in the thread. You can see that with a simple and
small action that is highlighted in the RFC guide as step 1 (gauge peo
we can easily do first
and take the first step towards making a statement in favor of a better
community.
On Tue, Jun 16, 2020, 00:50 Kalle Sommer Nielsen wrote:
> Hi
>
> Den tir. 16. jun. 2020 kl. 00.41 skrev Deleu :
> > People arguing BC breaks without even knowing the scope of
something
> better?
>
>
> --
> Best regards,
> Max Semenik
>
--
Marco Aurélio Deleu
t by adding the override functions
> while keeping the same base syntax.
>
> Mark Randall
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Marco Aurélio Deleu
ider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Marco Aurélio Deleu
Such a nice syntax. Even better than @@ and @. I wish this could get more
attention/traction.
On Wed, Jul 29, 2020, 19:46 David Rodrigues wrote:
> Oh, you are right! "yield from" is not common for me currently, so I really
> skipped it.
>
> In this case, is there some problem to apply it to Attr
I like and make use of interpolation, but I can't think of a use case for
this. Is there any valid use case that would benefit from this fix
regardless of personal preference? In other words, where would one use
string interpolation with an empty string being a valid case?
On Sun, Aug 9, 2020, 20:
| https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Marco Aurélio Deleu
Hi Nuno, thank you very much for kicking this off! The current state of
short closure is very limited and I believe it was a stepping stone to get
to this one.
This time there's no drawback of making fn a reserved keyword since it
already is.
This change will lead to better consistency and it will
in a slightly different way. The following would be much nicer:
>
> ```php
> public function update(int $numberId, int $addressId, bool $isMainNumber
> = false): void
> {
> $this->transaction->run(function () use (*): void {
>// Do all SQL queries for the update
> });
> }
>
> ```
>
> This would also increase code readability.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Marco Aurélio Deleu
On Wed, Mar 24, 2021, 17:20 Larry Garfield wrote:
> Greetings, Internalians.
>
> Some months back I proposed an RFC for short functions.
>
> https://wiki.php.net/rfc/short-functions
>
> After some discussion, I put it on hold to ensure that it was compatible
> with the other discussion floating a
ion,
> when they don't actually need any variable capture. An explicit syntax
> like "use(*)" instead makes this a deliberate choice.
> * There is no obvious way to expand it to support any by-reference
> capture, which is something people have previously expressed a desire for.
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Marco Aurélio Deleu
This would lead to inconsistent behavior in the language when short
closures auto capture without the auto keyword while multi statements
closure doesn't.
One of the best features of these RFC are their cognitive definition that
is clear, concise, consistent and simple.
On Sun, Mar 28, 2021, 11:26
n. 28. mar. 2021 kl. 13.02 skrev Deleu :
> >
> > This would lead to inconsistent behavior in the language when short
> closures auto capture without the auto keyword while multi statements
> closure doesn't.
> > One of the best features of these RFC are their cognitive def
rough programming syntax and throwing `fn` out would
be such a waste of that limited budget.
--
Marco Aurélio Deleu
I think you only need to handle merges locally if the pull request author
didn't sign their commits:
> You can always push local commits to the branch if the commits are signed
and verified.
> You can also merge signed and verified commits into the branch using a
pull request on GitHub.
> However,
That would be great!
I had an unpleasant experience with this "rule". You start disagreeing with
someone regarding an RFC and suddenly it becomes a reason to be called out.
Not to mention that when I was pointed to the internal rules and
guidelines, bottom posting is not explicitly listed as a rul
On Sat, Jun 5, 2021, 11:47 Pierre wrote:
> Le 04/06/2021 à 17:19, Nikita Popov a écrit :
> > Hi internals,
> >
> > I'd like to open the discussion on readonly properties:
> > https://wiki.php.net/rfc/readonly_properties_v2
> >
> > This proposal is similar to the
> > https://wiki.php.net/rfc/write
ed anything more
than just readonly as-is. I think the bigger picture here is how many use
cases are there that would vastly benefit from this Vs how many use cases
could potentially benefit from it but won't because of lack of cloning
support. Of course everyone's opinion will be shaped by the universe they
live in and in mine this RFC covers everything I need with no drawbacks and
I honestly don't understand not wanting this just because of lack of
cloning.
--
Marco Aurélio Deleu
On Tue, Jul 20, 2021, 20:35 Niklas Keller wrote:
> >
> > > > > nicolas-grekas wrote on the PR:
> > > > > > ?X&Y cannot be confused with
> > > > >
> > > > > It confused me. A compiler might understand it, but as a human I
> have
> > > > > trouble understanding it.
> >
>
> I think ?X&Y would be a p
major version
and I don't see a problem with that. Pure Intersection RFC was such a
breeze vote precisely because it didn't involve the complexity of mixing
with union. Part of that complexity is now being rushed after feature
freeze.
--
Marco Aurélio Deleu
On Sat, Jul 24, 2021, 07:33 Tobias Nyholm wrote:
>
> >>> Given both of these sets of assertions I would ask the RFC's author
> and proponents what would be a worse outcome?
> >>
> >> I don’t see how this question is relevant. We are not seeking
> compromises at the moment. We are seeking the best
Hello everyone!
A few months ago there was a proposed RFC for having wall clock time for
timeout [1]. It seemed like there was not a lot of push back against it [2]
with an exception of Nikita's comment about having 2 ini settings vs having
a toggle on the existing ini setting [3]
[1] https://wik
On Sun, Jul 25, 2021 at 2:07 PM Máté Kocsis wrote:
> Hi Deleu,
>
> What a coincidence! I've just added my PR to the "PHP 8.2" milestone on
> GitHub. That means, I'll definitely want to continue the work on this
> proposal
> as soon as I finish my previou
On Wed, Jul 28, 2021, 05:26 Pierre Joye wrote:
>
However my question was more about the rush for it, those are not easy to
> implement nicely, given the actual use cases, I am not sure it was worth
> this hurry. And I have the same feeling for this discussion about nullable
> intersection.
>
My
I started reading this thread with a total bias against it and as I read
through it I can only imagine how painful and annoying it is to maintain a
math library in PHP. Operator Overloading is truly a marvelous piece of
functionality for that domain.
However my biased still exists: it would be awf
Hi Jordan,
Does it make sense to explain in the RFC the difference between never and
mixed in this context? The RFC vaguely mentions that never can never be
used directly, but if it's limited to abstract class and interfaces, isn't
that already impossible to use directly? Or does it mean that the
On Sat, Aug 14, 2021, 14:48 G. P. B. wrote:
> On Sat, 14 Aug 2021 at 10:55, Deleu wrote:
>
>> Hi Jordan,
>>
>> Does it make sense to explain in the RFC the difference between never and
>> mixed in this context? The RFC vaguely mentions that never can never be
1 - 100 of 180 matches
Mail list logo
