don't want multiple versions of the same package on a single
application.
--
Marco Deleu
Hi!
It's been a few days since I wanted to send this email to internals, but
real life has been a bit chaotic so I apologize if it comes off as if I
didn't research the archives enough. I glossed over the Module conversation
from 10 months ago and the one that recently surfaced and after deeply
th
is good enough instead of export, but `use require` does seem
rather odd. import ... require (as opposed to import ... from) would also
work better-ish. In any case, this threads in bikeshedding space. I guess
I'd rather have use require anyway than not have it at all, specially
since IDEs often end up writing it for us anyway.
--
Marco Deleu
Marco Deleu
> On 18 Apr 2025, at 14:54, Niels Dossche wrote:
>
> Hi
>
> Since this is a policy change, doesn't this need an RFC as well?
>
> Kind regards
> Niels
One can argue that this isn’t a policy change but rather just tooling to help
enforce a po
outine. Shouldn't await be used for that instead? Would making
`suspend` a fatal error inside the main flow somehow worse for
implementation?
Sorry for not reading the entire RFC before replying. I hope to get through
it all in the following days.
Thanks!
--
Marco Deleu
but more on the semantics of how to go about
the statement itself.
But as I stated, it doesn't feel like the effort is worth the benefit
because even if this could be implemented in a 1-line-of-code on php-src,
it still means syntax change which will affect tooling and cause a ton of
open-source overhead with token_get_all() changes, etc.
--
Marco Deleu
> On 15 Nov 2024, at 20:42, Rob Landers wrote:
>
>
>> On Sat, Nov 16, 2024, at 00:34, Juris Evertovskis wrote:
>> Hey all,
>>
>>
>>
>> If you try to implement an interface that does not exist, you get the
>> ‘Interface “%s” not found’ error. Usually that’s useful as it points to a
>> cod
he US government also fund the PHP Project or just use it? To what
extent does their funding go? What is their contribution that makes it
worth excluding an entire nation worth of volunteers?
AFAIK, the PHP project is not an american corporation and as such is not
subject to USA executive orders?
--
Marco Deleu
> On 24 Oct 2024, at 03:27, Larry Garfield wrote:
>
> Bundling Composer with PHP is an entirely different question with a host of
> additional concerns to consider, like whether the Composer maintainers would
> even want that. Let's please stay focused on the topic at hand.
>
> --Larry Garf
HP tooling,
but it seems pretty clear to me that any framework would be better than no
framework because the alternative is that a framework will be built
in-house and nobody in the world will have prior experience with that one.
--
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
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
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
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
> On 11 Aug 2024, at 13:59, Christoph M. Becker wrote:
>
> On a general note, the whole administrative part of the RFC process
> feels like we're stuck in the 20th century. For instance, to start the
> vote, you are supposed to:
>
> * update the RFC page to "voting" status
> * add the doodle
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
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
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
> On 20 Jul 2024, at 11:30, Tim Düsterhus wrote:
>
> Hi
>
>> On 7/19/24 00:51, Christoph M. Becker wrote:
>> And frankly, how much code would be affected? I mean, does anybody
>> actually put a comment between `yield` and `from`? Is there a case
>> where this may make sense? "Because we ca
wi be done and it must be supported. If a
Ubuntu LTS user gets an error, pointing out that they're relying on an
accidental behavior only present in 9 patch releases of the entire PHP
lifecycle seems good enough.
> On 18 Jul 2024, at 16:05, Tim Düsterhus wrote:
>
> Hi
>
>
> On 17 Jul 2024, at 20:16, Juliette Reinders Folmer
> wrote:
>
> Hi all,
>
> I recently discovered a change was made to the Tokenizer in PHP 8.3.0 which
> now allows for a comment to exist between the `yield` and `from` keyword from
> the `yield from` keyword.
> Before PHP 8.3, this was a
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
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
Marco Deleu
>
>> You may have core developers that voted no due to maintenance burden, but if
>> said maintainer is no longer active and new maintainers don't mind it, it's
>> a moot argument because people changed.
>
> The maintenance burden argume
> On 15 Jun 2024, at 14:11, Rowan Tommins [IMSoP] wrote:
>
> I fundamentally disagree with this assertion.
>
> If somebody makes a valid point, it doesn't automatically become invalid
> because time has passed, or because nobody happens to repeat it in a later
> e-mail thread.
>
> If I cop
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
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
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
Marco Deleu
> On 19 Mar 2024, at 14:51, Ilija Tovilo wrote:
>
> Hi Robert
>
>> On Tue, Mar 19, 2024 at 5:24 PM Robert Landers
>> wrote:
>>
>> I've been thinking about this as an RFC for awhile, but with generics
>> being far off (if at a
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
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
}
}
```
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
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
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
, 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
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
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
there any
controversial thoughts around it?
Thanks!
--
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
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
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
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
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
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
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
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
ided by
core.
* If naming is an issue to you, I'd also be fine with
`array_value_first()`.
--
Marco Deleu
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:
> >>
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
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
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
Marco Deleu
> On 6 Oct 2023, at 19:39, Ben Ramsey wrote:
>
> On 10/6/23 11:18, Jakub Zelenka wrote:
>> Hi,
>>> On Fri, Oct 6, 2023 at 2:44 PM Ilija Tovilo wrote:
>>> https://wiki.php.net/rfc/rfc1867-non-post
>>>
>>>
>> It shou
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
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
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
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
lectively getting Voting Karma so that we can have these
awesomeness revisited.
--
Marco Deleu
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
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
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
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
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
p
>
>
That's wonderful news Levi! Good luck to us all on this RFC!!
--
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
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
>
> 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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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 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 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, 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, 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, 1:17 PM Pierre Joye wrote:
> hello,
>
>
> On Sun, Apr 9, 2023, 1:37 AM Stephan Soller
> wrote:
>
> > Hello,
> >
> > I'm sorry if this isn't the correct mailing list for that discussion but
> I
> > couldn't find a more appropriate one where people actually know how the
> > w
about PHP internals function is to assume the
first word is a class, such as:
$autoload = new Autoload();
And then everything after the first underscore is a method name, such as
$autoload->register_class();. What I can recommend in this case is to make
them autoload_register_class_loader() and
autload_unregister_class_loader(), but prefixing everything with register_*
would be essentially $register = new Register();, but register what?
--
Marco Deleu
On Sat, Apr 8, 2023, 6:04 PM Ilija Tovilo wrote:
>
> Sadly, there's a conflict of interest here. There are people who want
> to keep running their existing websites without having to make any
> changes, and there are people who are using PHP daily and would like
> to see the language evolve. We w
On Sun, Apr 9, 2023, 7:10 PM Kamil Tekiela wrote:
>
> I'd rather say that the roadblocks people are facing in upgrading legacy
> projects are not specific to PHP 8, but rather a technical debt acquired
> over the past 10-15 years. Even if nothing would change in PHP 8, people
> would still compla
hat deprecation error, tough luck if you didn't".
I love PHP and I built my career around it. I have zero interest in
starting from scratch in another language, but I've lost count on how many
projects, friends and companies around me have already made the switch to
Typescript. It's getting harder and harder to argue in favour of staying
with PHP.
--
Marco Deleu
On Sat, Apr 8, 2023, 5:47 PM Dan Liebner wrote:
> I agree with the OP's sentiment here. If I was starting a codebase from
> scratch today, I'd probably go with Node. I find that writing modern
> JavaScript is way easier than writing PHP these days, and the breaking
> changes in newer PHP versions
On Wed, Mar 1, 2023, 12:02 PM Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> wrote:
> Hi Deleu,
>
> śr., 1 mar 2023 o 16:54 Deleu napisał(a):
>
>>
>>
>> On Wed, Mar 1, 2023 at 9:36 AM Michał Marcin Brzuchalski <
>> michal.brzuchal...@gmail.
ave a complex distribution system
that differs greatly between Windows, Debian, Ubuntu, Alpine Linux, AWS
Lambda, etc. I wish one day we could have something as simple and
ubiquitous as Composer installing PHP extensions, but until then the less
amount of extensions the better for end users.
--
Marco Deleu
king stuff, send these
stuff to him and ask him to see for himself the consequences of his
changes. Maybe he can decide for himself that reverting is the best
approach or maybe he can use his energy to fix even deeper issues.
--
Marco Deleu
On Tue, Feb 21, 2023, 8:52 AM someniatko wrote:
> Hi again, internals
>
> My marathon of some crazy ideas continues :D, with less crazy one this
> time.
>
>
> ## Idea
>
> Allow "reimplementing" the non-static public API (that is public
> properties and methods, excluding constructor) of a class b
On Thu, Feb 2, 2023, 11:22 AM someniatko wrote:
> I'd like to also emphasize that the concept of compilation and static
> type-checking / analysis is not foreign to the PHP community. Major
> frameworks like Symfony already have a concept of compiling e.g. a DI
> container, and static analyzers l
> >
> > Mocking
> >
>
> This isn't a terribly compelling argument. Readonly classes are typically
> value objects; it's rare that you will mock them as they will be used as
> messages or results, and you'll end up doing assertions against them — not
> mocking them.
>
> Anything else it would enable
On Mon, Jan 23, 2023, 1:16 PM Ollie Read wrote:
> Oh, I didn't mean to suggest that it automatically binds.
>
> My second suggestion for how to achieve this does require some sort of
> automation. If you create a closure from Str::someMethod($arg1, $arg2)
> where someMethod isn't static, it shoul
>
>
> The vote has now closed.
>
> The final result is 14 Yes, 12 No, which is less than the required 66%.
> The RFC is declined.
>
Highly interesting to see that there's a theoretical path with a different
syntax that takes 4 voters to yes and change the outcome to 18/26, which
would have been an
1 - 100 of 172 matches
Mail list logo
