ifferent 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
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
would behave similarly.
Thoughts?
--
Marco Aurélio Deleu
rting 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
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,
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
+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
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 the change
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
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_int` will not return tru
oked
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's feelings towards having a
>&
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
ttps://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
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
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
> >
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
cit 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,
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 definition
> that is clea
ng `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.
>
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
t; I see that we have different views of this. And I understand that you are
> happy with this change, but only for 8.2.
>
>
I hope one day I'll have built up so much experience, knowledge and
confidence to call a 30 x 3 vote of the selective people that can cast a
vote "a mistake".
--
Marco Aurélio Deleu
On Tue, Aug 24, 2021, 19:28 Derick Rethans wrote:
> On Mon, 23 Aug 2021, Deleu wrote:
>
> > We recently had the Nullable Intersection Types RFC process in an
> > unconventional way starting a new RFC post feature freeze. If memory
> > serves me right, another s
>
> Situations like this often requires a judgement call rather than something
> that could be defined as a policy.
> I suggest the release managers always should be in agreement before a RFC
> is created during a “feature freeze”. If the release managers agree that a
> change can be added, then
shown his support on this
discussion in the first reply of this thread.
--
Marco Aurélio Deleu
ike a great idea, assuming appropriately scoped.
>
> -Sara
>
That's wonderful to read! I'm looking forward to refining the scope as
necessary. One question I have for experienced release managers is whether
clause 11 is good/bad and whether it should mention a specific number of
days or leave it open for judgement calls.
--
Marco Aurélio Deleu
etter doesn't make it a mess.
Ultimately, the language syntax is how we communicate with the computer and
more importantly how we read and understand the code. It has a great impact
on code using `token_get_all()` and is always a delicate matter. An RFC
targeting controversial syntax change in post feature-freeze is ...
challenging.
--
Marco Aurélio Deleu
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
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 Sun, Aug 15, 2021, 12:43 Lynn wrote:
> My only feedback is that it should not be called `never`. If I see `never`
> as the parameter type, I read this as never being allowed to pass anything,
> which means that `foo('something')` with `foo(never $something)` will
> result in a compile error.
be
included/excluded in the RFC.
Marco Aurélio Deleu
On Wed, Aug 25, 2021 at 9:00 PM Ben Ramsey wrote:
> Derick Rethans wrote on 8/24/21 12:35:
> > On Mon, 23 Aug 2021, Deleu wrote:
> >
> >> In order to not be empty-handed, I started a gist that can be seen as
> >> the starting point for this discussion, availabl
On Wed, Aug 25, 2021 at 10:25 PM Ben Ramsey wrote:
> Deleu wrote on 8/24/21 13:53:
> > The proposal is rooted in making it easier for release managers and rfc
> > authors to refine code changes that may or may not be necessary to
> > accomplish a previously approved RFC.
&
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
hat when I tried
to contribute to Alpine Linux, one of the major turn off was GitLab
hosting. I had already decided to spend time and effort learning about the
project and then having to learn about their ticketing system and git
repository is just unnecessary extra work.
PHP should not distance itself from its user base.
--
Marco Aurélio Deleu
redits-open-source-projects/
--
Marco Aurélio Deleu
On Tue, Nov 16, 2021, 00:36 wrote:
> L.S.,
>
> As some of you may have seen, I posted a thread on Twitter a few days
> back referencing this RFC:
> https://twitter.com/jrf_nl/status/1459221549429542920
>
> I've been asked to post the link to the Twitter discussion in this
> thread for
APIs to replace the old ones because
nobody can ever know how many combinations of possible input parameters
there are.
--
Marco Aurélio Deleu
notice and more worried about what happens in
> PHP 9 when it's a fatal error.
>
I can't say that this line of reasoning has its merits, but then there's no
benefit to the engine itself. Issuing a warning and carry on materializing
dynamic properties will never bring the original performance improvement
that was part of the original state of the RFC.
--
Marco Aurélio Deleu
recation time
> as
> > possible; if people are misunderstanding deprecations and abusing them,
> > that's... a different problem that cannot be solved by not issuing
> > deprecations.
> >
> > --Larry Garfield
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
> I don't think this should be deprecated or removed at all. However, I agree
> that if it is going to be removed, the more time/versions that exists
> between deprecation and removal, the better.
> --
> Chase Peeler
> chasepee...@gmail.com
>
I agree with previous replies and would even go as further to say that it
is better to try and avoid deprecation on the last version of a PHP Series.
I like this deprecation, but I also think it's a pretty big deprecation to
happen only 1 year before it's actual removal. Deprecating it now means
people will have at least 3 years to adjust to it. Recently Laravel also
made the same changes that PHPUnit did to stop converting deprecations into
fatal errors so that users can still use deprecated code if they need more
time to accommodate.
--
Marco Aurélio Deleu
ink
moving to where developers are is a good decision because it becomes more
accessible for a lot of people that may be willing to help.
Self hosting means that 1) the choice of system will be something that the
pool of people experienced in it will be less than GH Issues 2) someone
will have to maintain the hosting infrastructure for it 3) it will be less
accessible. I'm all for using GH Issues.
--
Marco Aurélio Deleu
w.php.net/unsub.php
>
>
If this were to happen, would it be an attribute to be added to the
functions, a new keyword to declare named-parameter functions only or a
different way to declare parameters? Are there other options?
--
Marco Aurélio Deleu
On Tue, Jul 20, 2021, 20:35 Niklas Keller wrote:
> >
> > > > > nicolas-grekas wrote on the PR:
> > > > > > ?X cannot be confused with
> > > > >
> > > > > It confused me. A compiler might understand it, but as a human I
> have
> > > > > trouble understanding it.
> >
>
> I think ?X would be a
e 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
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]
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 previous tasks.
&
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
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 to put
l 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
lass/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
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
y) ?? 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
ure 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
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 =&
ers 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
ng 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
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:
> >>
* If naming is an issue to you, I'd also be fine with
`array_value_first()`.
--
Marco Deleu
rload `~=` 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
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
hort, 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
rate scope for a
function". PHP has several language constructs that may or may not create a
separate scope.
Delimite Scope: function, method, class, procedural file
Shared scope: if, for, foreach, include, require and fn
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Marco Aurélio Deleu
On Thu, Jun 16, 2022, 9:10 AM Pierrick Charron wrote:
> Hi internals,
>
> Since its version 6.62.0 [1], libcurl features a brand new URL API [2] that
> can be used to parse and generate URLs, using libcurl’s own parser. One of
> the goals of this API is to tighten a problematic vulnerable area
On Sun, Jun 12, 2022 at 2:29 PM Rowan Tommins
wrote:
> On 11/06/2022 23:01, Deleu wrote:
> > The RFC does mention that the existing Anonymous Function Syntax
> > remains untouched and will not be deprecated. Whether the new syntax
> > is better for nearly all closures will
RFC.
>
> No, it makes me want to make the new syntax as useful as possible.
>
On the sentiment, we can agree. It just happens that from where I'm
standing, any change to the proposed syntax will make it less useful.
--
Marco Aurélio Deleu
On Sat, Jul 30, 2022, 4:48 PM David Gebler wrote:
>
>
> What I'm asking is what's the practical use for this proposed function?
> Where are you likely to need to know if a string is valid JSON but not have
> to (try to, with error handling) parse it almost immediately afterwards
> anyway?
>
I'm
t a valid
JSON (really awkward) and the option of using `json_last_error()` relies on
an internal state instead of an immutable structure. Effectively, what we
need is to return a complex structure which can contain a boolean and a
string and that is a class/object.
Thoughts?
--
Marco Deleu
On Thu, Aug 25, 2022, 9:12 PM David Gebler wrote:
>
> I agree that the number of userland implementations for a "is_valid_json"
> type function including in some widely used frameworks and systems
> indicates there's some degree of demand in the ecosystem for validating a
> JSON string.
>
I
On Tue, Sep 13, 2022, 7:58 PM Mel Dafert wrote:
> The options I see feasible are:
> - A new ini setting `max_input_vars_abort` (default to 0), which, if set
> to 1, will abort the request if there are more input variables than
> allowed.
> - A method to reliably detect whether the input vars
On Wed, Oct 5, 2022, 7:54 AM juan carlos morales
wrote:
>
> Apply a PECL strategy to try experimental features might not be the
> convenient way always, for example, if we create a new ... sensitive
> ... ini setting that affects the behavior of PHP somehow, then ...
> maybe applying the PECL
ould be powerful enough to solve a lot of usability on
PHP OOP while not being crazy enough to create a nightmare on codebases and
the internals of the PHP Engine. Does this make sense?
--
Marco Deleu
On Wed, Aug 10, 2022, 11:30 PM Rowan Tommins
wrote:
>
> To be honest, I put them in that order more for "purity" reasons: if they
> come before __call, they can change the existing behaviour of the class, by
> defining an extension method with the same name as a "virtual" method
> implemented
e, I just fallback to private +
getter and the nice thing about it is that it creates a consistent mindset
that if a property is being accessed via a getter, then the reader should
be advised that the property may change depending on WHEN it's accessed.
--
Marco Deleu
On Sun, Dec 4, 2022, 8:43 PM j adams wrote:
> I apologize if I have the wrong mailing list here. I'm hoping ot ask the
> PHP developer community if there's any appetite for functions to handle
> matrix operations and scientific computing.
>
> I took a course on machine learning which had us code
tic notion. This doesn't
have to be complex and limiting child classes makes it more complex. In the
future, the education around readonly keyword will be that it has no
bearings anywhere except the class that makes use of the keyword.
--
Marco Deleu
whelming amount of choices to be made. If this
class can cover 80% of the use-case, folks can extend it to build their
remaining 20% advanced use-case and PHP becomes easier. I really look
forward to more basic utility-classes built-in and ready to go.
--
Marco Deleu
various places. It's not the world-destroyer people make it out
> to be.
>
Do you honestly think that everyone with a small/medium PHP project
(500k~1M LOC) out there has someone as competent as you capable of
achieving what you did? That is definitely a dream rock to live under.
--
Marco Deleu
On Thu, Dec 15, 2022, 3:16 PM Tim Düsterhus wrote:
>
> [1] The 'Text' class should likely be made final, because folks might
> otherwise rely on a specific userland extension, preventing actual
> interoperability.
>
I'm fond of final classes but in here I think it *adds* burden to core
On Sat, Nov 26, 2022, 4:45 PM Máté Kocsis wrote:
> We proposed this change because it wouldn't break anything that's already
> not "broken".
>
> Regards:
> Máté
>
The example provided already raised some eyebrows from people. I think the
argument of "let's furthet enhance this 'broken'
stion then
becomes: why is this being proposed and is it worth it?
As I read through the RFC, the only reason this is being proposed is
because "it breaks decoration via inheritance". Doesn't `final` cause the
same issue? How is this problem being handled if the class is marked as
final? If you can't extend a final class to build your "decoration via
inheritance", why can't the same argument be applied to readonly classes?
--
Marco Deleu
> >
> > 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
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
>
>
> 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
e honest, I think asymmetric visibility seems way over complex for very
little benefit, so I'm a bit against the entire feature, but if we were to
have them, it would really be nicer to not have crazy shenanigans involved.
--
Marco Deleu
tected(set) readonly $var`
The code `private readonly $var` should not have any change.
--
Marco Deleu
ion that `public public(set) readonly` is
not something needed to be supported.
--
Marco Deleu
f 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
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
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...@g
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
dn'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
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
rom 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
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
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
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 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
1 - 100 of 147 matches
Mail list logo
