of traits + interfaces on hold until there's clarity
about interface default methods.
Kind regards
Brent
On Tue, Sep 10, 2024 at 11:03 PM Gina P. Banyard wrote:
> On Tuesday, 27 August 2024 at 09:25, Brent Roose <
> brent.ro...@jetbrains.com> wrote:
>
>
> Back to PHP, using tra
community is open to it as well, given the examples with Laravel’s default
implementation traits, static analyser support, as well as the interface
default methods RFC last year.
If internals are open to the idea, I would like to draft a proper RFC for
it. Please let me know your thoughts!
Brent
unlearn the "only
one return per method rule" we were taught in college
Brent
> On 12 Jul 2023, at 20:17, Larry Garfield wrote:
>
> On Wed, Jul 12, 2023, at 4:00 AM, G. P. B. wrote:
>> On Mon, 3 Jul 2023 at 01:11, Levi Morrison wrote:
>>
>>> Chatter on
those points, sorry if my previous mail caused any
inconvenience.
Kind regards
Brent
> On 28 Jul 2021, at 09:29, Nicolas Grekas wrote:
>
> as proposed by Nikita and Joe, I'm submitting this late RFC for your
>> consideration for inclusion in PHP 8.1. Intersection types as cur
way to go
Sidenote: weren't there any prior cases where an RFC was accepted only to have
found out an oversight which resulted in that RFC to be postponed to the next
release?
Kind regards
Brent
> On 26 Jul 2021, at 16:14, Sara Golemon wrote:
>
> On Fri, Jul 23, 2021 at 4:58 AM
> On 7 Jul 2021, at 23:16, Larry Garfield wrote:
>
> On Wed, Jul 7, 2021, at 7:32 AM, Brent Roose wrote:
>> Hi internals
>>
>> With the readonly properties RFC almost certainly accepted, I'd like to
>> discuss an idea that's slightly related to the
ing property accessors [2]
- Swift supports them via Protocols [3]
Looking forward to hearing your thoughts.
Kind regards
Brent
[1] https://www.typescriptlang.org/docs/handbook/type-compatibility.html
<https://www.typescriptlang.org/docs/handbook/type-compatibility.html>
[2]
https
throw the word `deadend` or something similar into the
> ring, to make things a bit clearer.
>
> Thanks,
> Peter
Kind regards
Brent
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
; for a previous discussion
but could only find https://externals.io/message/111297#111298
<https://externals.io/message/111297#111298>
Kind regards
Brent
since class linking can now
also happen at runtime?
Kind regards
Brent
> On 5 Feb 2021, at 15:03, Dmitry Stogov wrote:
>
> Hi,
>
> I'm glad to present the result of my recent work - Inheritance Cache.
>
> https://github.com/php/php-src/pull/6627
>
> This is a
words: "will this method accept this
value?"
Is that in line with your view on `acceptsValue`?
Kind regards
Brent
> On 29 Jan 2021, at 10:33, Nikita Popov wrote:
>
> On Fri, Jan 29, 2021 at 9:15 AM Brent Roose <mailto:bre...@stitcher.io>> wrote:
> Hi Internals
&g
like so:
```
if (! $type->accepts(ShouldBeStored::class)) {
return;
}
// …
```
I believe this method should accept both class names and objects to be
consistent with the existing reflection API. It would also work with
intersection types, if they are to be added some day.
What do you think?
port, but it's not a real standard. Maybe the FIG would one day
step in to decide these kinds of things, but the reality is that many major
frameworks don't follow FIG as closely as they used to. I think there's value
in adding attributes in the core, with the goal only being sta
always be the more concise way.
- If you'd use enum objects for handling complex state, you're better off using
classes and properly implementing the state pattern.
I don't think enum objects should be a blocker, if people _really_ want it then
fine. Based on my experience though,
to promote PHP, one you can share with both PHP and non-PHP developers, and
teases the right amount to get some people interested. A perfect page to share
on hackernews, reddit, twitter and the likes. I think it's a great first step!
Kind regards
Brent
> On 14 Oct 2020, at 13:18, Dik T
nput on Nuno's PR from a techinical point of view:
what's missing, what's needed to get this to the RFC phase, … and not only
discussions about what syntax we like or not, or whether there are other ways
to solve the same problem. Please provide Nuno with actionable feedback.
Kind
Hi Nikita
From a userland point of view, I'd indeed expect this example to use
strict_types, because it's declared in UseOfMyAttribute.php. Is this something
that can be changed still?
Kind regards
Brent
> On 22 Sep 2020, at 14:58, Nikita Popov wrote:
>
> Hi internals,
&
types at runtime, since static analysis truly takes care of them.
Thanks Matthew for pitching in, I believe the opinion of the ones building and
maintaining the current static analysis toolset in PHP is essential in this
discussion.
Kind regards
Brent
> On 17 Sep 2020, at 23:00, Matthew Brown wr
Hi Ilija
> On 17 Sep 2020, at 19:01, Ilija Tovilo wrote:
>
> Hi Brent
>
>> Today I'd like to hear your thoughts on what might be a controversial topic,
>> though I think it's worth having this discussion. I want to make the case
>> for adding gener
t; public $__T;
>
> public function add(mixed $item) {
>if (!$item instanceof $this->__T) {
> throw new TypeError();
> }
> }
> }
> $c = new Collection().
> $c->__T == 'Product';
>
> Which is essentially what you can do in userspace
Hi George
Thanks for the reply!
> On 17 Sep 2020, at 14:34, G. P. B. wrote:
>
> Hello Brent,
>
> I'm going to make the argument I've already done on Reddit once [1], IMHO
> TypeScript is just a nicer pipeline for a preprocessor and a static
> analyser and not
performance impact
- The PHP community is already embracing static analysis
- Transpiling has been proved to be a viable workflow, thanks to TypeScript
- As with all things-PHP: it's opt-in. You don't have to use the syntax if you
don't want to and you won't experience any downs
lh9/jit_benchmarks_on_reallife_web_applications/fwuje8g/>).
In other words: not one value with several integer flags, but dedicated
options for every configuration entry. Is this still on the roadmap?
Kind regards
Brent
> On 15 Sep 2020, at 07:05, Dmitry Stogov wrote:
>
> This also
just a little more clean, a little less
verbose, a bit more convenient.
PHP has been maturing over the last years, which means there's room, and need,
for things that aren't strictly necessary.
Kind regards
Brent
> On 3 Sep 2020, at 09:18, Stanislav Malyshev wrote:
>
>
ed for official community polls, I feel like the
key figures of PHP's core team already do listen to the community.
Kind regards
Brent
> On 20 Aug 2020, at 15:48, Kalle Sommer Nielsen wrote:
>
> Den tor. 20. aug. 2020 kl. 01.07 skrev Stanislav Malyshev
> :
>> Please f
before feature-freeze. I suppose the
RMs should have a final say in this descision?
Kind regards
Brent
> On 22 Jul 2020, at 14:46, Benjamin Eberlei wrote:
>
> On Wed, Jul 22, 2020 at 2:40 PM Deleu wrote:
>
>> "Terrible" is the amount of humans having their lives taken
Hi Levi
I personally almost never use assert, and actually assumed it would throw an
error, so this sounds like a good change!
Have you done research on how this would affect the top-1000-ish popular
packages like Nikita does?
Kind regards
Brent
> On 20 Jul 2020, at 15:48, Levi Morrison
mpact, at least not on modern-day
projects.
Kind regards
Brent
> On 15 Jul 2020, at 11:10, Nikita Popov wrote:
>
> On Wed, Jul 15, 2020 at 10:56 AM Brent Roose <mailto:bre...@stitcher.io>> wrote:
>
>> Hi Nikita
>>
>> Yes that would be nice, if it's n
Hi Nikita
Yes that would be nice, if it's not too much of a hassle. I'm only able to test
this in one or two large Laravel projects, so it would still be a limited test.
Kind regards
Brent
> On 15 Jul 2020, at 10:53, Nikita Popov wrote:
>
> On Wed, Jul 15, 2020 at 1
Hi Nikita
Is the ini setting available in current 7.4 builds? Is it documented somewhere?
I'd like to test this change in some of our projects.
Kind regards
Brent
> On 15 Jul 2020, at 10:28, Nikita Popov wrote:
>
> On Tue, Jul 14, 2020 at 11:47 PM Björn Larsson <ma
d and a revote
should happen, but it shouldn't affect the vote of this RFC, which has a larger
impact than just the attributes syntax.
Kind regards
Brent
> On 14 Jul 2020, at 11:09, Nikita Popov wrote:
>
> On Thu, Jul 9, 2020 at 4:33 PM Nikita Popov <mailto:nikita@gmail
s would solve ~80% of my problems with PHP's current type
system, and I figure there are lots of developers in a similar situation. If I
remember correct from my college days, Java also supports both styles: Int[]
and ArrayList.
All that to say that maybe it's worth the effort lookin
he PHP community, that will be chosen by those
> with php.net VCS accounts
> • Lead developers of PHP based projects (frameworks, cms,
> tools, etc.)
> • regular participant of internals discussions
I would think Nicolas' application would at least re
for-homebrew-in-mac-osx-mojave/>),
though this tool doesn't seem to work anymore in recent MacOS versions.
Kind regards
Brent
Hi Michał
I can't help but wonder: why did you start the vote to begin with? It seemed to
me that, based on the discussion feedback, it would never pass in its current
form.
Kind regards
Brent
> On 24 Oct 2019, at 09:41, Michał Brzuchalski
> wrote:
>
> Hi all,
>
&g
improve the system. I hope core members like yourself will make the
same effort in the near future, so that months of having the same discussions
can finally end.
Kind regards
Brent
On 27 Sep 2019, 08:00 +0200, Zeev Suraski , wrote:
> On Fri, Sep 20, 2019 at 12:52 PM Zeev Suraski wrote:
>
Hi Paul
On 20 Sep 2019, 16:04 +0200, Paul M. Jones , wrote:
>
>
> > On Sep 20, 2019, at 01:25, Brent wrote:
> >
> > Moderators are no dictators
>
> Maybe, maybe not.
>
> But moderators can and do play favorites, banning or silencing one voice (of
> whom th
gards
Brent
On 19 Sep 2019, 19:19 +0200, Dan Ackroyd , wrote:
> Hi internals,
>
> Here is an RFC to "Prevent disruptions of conversations"
> https://wiki.php.net/rfc/prevent_disruptions_of_conversations?do=edit
>
> A couple of notes:
>
> * although the RFC would only
://externals.io/message/106012)
Maybe someone has a good suggestion on how people can voice their opinion on
the future of PHP, without polluting several RFC discussions.
Kinds regards
Brent
Hello Zeev
Would you mind sharing with us why you specifically would be able to single
handedly decide what gets merged into PHP and what not?
Kind regards
Brent
On 13 Sep 2019, 01:56 +0200, Zeev Suraski , wrote:
>
> > On 13 Sep 2019, at 2:50, Joe Watkins wrote:
> >
> > Ze
g the main discussion from the PR will cause unnecessary
confusion: important, generals remarks could be made on the "main thread", and
I think there's value in keeping these remarks together with everything else.
Kind regards
Brent
On 6 Sep 2019, 16:48 +0200, Nikita Popov , wrote:
&
tform will take more manpower and resources, which are better invested
somewhere else — the development of PHP perhaps?
I believe GitHub is the way to go. Several large communities manage their OSS
on it and have proven it works, PHP should simply do the same.
Kind regards
Brent
On 5 Sep 2019, 15:1
Hi Côme
> Huge "no" from me on using github for discussing RFCs.
Care to elaborate why? The majority seems to like it. Though I am also curious
about Nikita's experience with it, as he is the one having to process the
feedback.
Kind regards
Brent
On 5 Sep 2019, 11:40 +0
version depending on the code wasn't clear to
me.
Kind regards
Brent
On 8 Aug 2019, 23:59 +0200, Zeev Suraski , wrote:
> On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov wrote:
>
> > On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov wrote:
> >
> > > On Thu, Aug 8, 2019
ments altogether because of this, as there's no way to gather accurate data
about the usage of short open tags, let alone know how many developers using
them actually plan on ever upgrading to 7.4…
Kind regards
Brent
On 8 Aug 2019, 12:27 +0200, Côme Chilliet , wrote:
> Le mercredi 7 aoû
45 matches
Mail list logo
