/ 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
requiring another RFC vote).
Making it mixed on version 1 means that support for the mixture of them can
never be undone.
--
Marco Deleu
d 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 all),
oposal 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
r
}
}
```
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
) 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
dmin/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
.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
t 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
f
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
controversial thoughts around it?
Thanks!
--
Marco Deleu
ch 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
-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
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
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
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
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
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
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
* 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 =&
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
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
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
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 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
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
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
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
ly 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
werful 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
;
That's wonderful news Levi! Good luck to us all on this RFC!!
--
Marco Deleu
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
xpected?
```
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
ntation 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 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
> > under t
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
ould 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
il.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
kage 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
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
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
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
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
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 that "
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,
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
> >
t 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
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
ve 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
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
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
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
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
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
> >
> > 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
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
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 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
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
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'
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
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
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
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
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 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
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
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 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
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
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 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
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
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
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
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
1 - 100 of 147 matches
Mail list logo
