On Mon, 7 Jul 2025 at 15:57, Larry Garfield wrote:
>
> On Fri, Jul 4, 2025, at 6:50 PM, Andreas Hennings wrote:
> > On Thu, 3 Jul 2025 at 23:44, Larry Garfield wrote:
> >>
> >> On Thu, Jul 3, 2025, at 12:49 PM, Andreas Hennings wrote:
> >>
> >&g
On Thu, 3 Jul 2025 at 00:26, Andreas Hennings wrote:
>
> This topic was discussed in the past as "Declaration-aware
> attributes", and mentioned in the discussion to "Amendments to
> Attributes".
> I now want to propose a close-to-RFC iteration of this.
> (I
Thank you Ilja!
On Sat, 5 Jul 2025 at 19:47, Ilija Tovilo wrote:
>
> Hi Andreas
>
> On Sat, Jul 5, 2025 at 7:29 PM Andreas Hennings wrote:
> >
> > Hello internals,
> > I would like to ask for RFC karma for my wiki account, username
> > "donquixo
Hello internals,
I would like to ask for RFC karma for my wiki account, username "donquixote".
I have been active on this list in the past, I work with php and
Drupal, I have the same username in github.
My first RFC might just be a reduced version of the "target-aware
attributes" idea I proposed
On Thu, 3 Jul 2025 at 23:44, Larry Garfield wrote:
>
> On Thu, Jul 3, 2025, at 12:49 PM, Andreas Hennings wrote:
>
> >> A setter method injection is what I did in AttributeUtils, because it was
> >> the only real option.
> >
> > In my experience, this
On Sat, 5 Jul 2025 at 00:11, Rob Landers wrote:
>
>
>
> On Fri, Jul 4, 2025, at 17:21, Andreas Hennings wrote:
>
> On Fri, 4 Jul 2025 at 06:30, Stephen Reay wrote:
> >
> >
> >
> > On 4 Jul 2025, at 00:54, Andreas Hennings wrote:
> >
>
On Fri, 4 Jul 2025 at 06:30, Stephen Reay wrote:
>
>
>
> On 4 Jul 2025, at 00:54, Andreas Hennings wrote:
>
> On Thu, 3 Jul 2025 at 19:17, Stephen Reay wrote:
>
>
>
>
>
> Sent from my iPhone
>
> On 3 Jul 2025, at 23:40, Larry Garfield wrote:
>
On Thu, 3 Jul 2025 at 19:17, Stephen Reay wrote:
>
>
>
>
> Sent from my iPhone
> > On 3 Jul 2025, at 23:40, Larry Garfield wrote:
> >
> > On Wed, Jul 2, 2025, at 5:26 PM, Andreas Hennings wrote:
> >> This topic was discussed in the past as "Decla
On Thu, 3 Jul 2025 at 18:29, Larry Garfield wrote:
>
> On Wed, Jul 2, 2025, at 5:26 PM, Andreas Hennings wrote:
> > This topic was discussed in the past as "Declaration-aware
> > attributes", and mentioned in the discussion to "Amendments to
> > Attributes
This topic was discussed in the past as "Declaration-aware
attributes", and mentioned in the discussion to "Amendments to
Attributes".
I now want to propose a close-to-RFC iteration of this.
(I don't have RFC Karma, my wiki account is "Andreas Hennings (donquixo
On Wed, 25 Jun 2025 at 13:56, Christian Schneider wrote:
>
> Am 25.06.2025 um 12:37 schrieb Gina P. Banyard :
> > While working on the deprecation to/from bool type juggling in functions
> > RFC and seeing the impact within Symfony, we found a common slightly
> > annoying case.
> > The getDocCom
On Wed, 11 Jun 2025 at 21:37, Andreas Hennings wrote:
>
> On Thu, 5 Jun 2025 at 16:43, Volker Dusch wrote:
> >
> > On Wed, Jun 4, 2025 at 6:41 PM Larry Garfield
> > wrote:
> >>
> >> While I support this RFC and want to see it in, I have voted no for 2
On Thu, 5 Jun 2025 at 16:43, Volker Dusch wrote:
>
> On Wed, Jun 4, 2025 at 6:41 PM Larry Garfield wrote:
>>
>> While I support this RFC and want to see it in, I have voted no for 2
>> reasons.
>>
>> 1. The switch to an array parameter, as previously noted, is a major DX loss
>> for unclear ben
On Mon, 19 May 2025 at 17:13, Nicolas Grekas
wrote:
>
>
>
> Le lun. 19 mai 2025 à 16:30, Andreas Hennings a écrit :
>>
>> On Fri, 16 May 2025 at 21:59, Nicolas Grekas
>> wrote:
>> >
>> >
>> >
>> > Le jeu. 15 mai 2025 à 16:06, La
On Fri, 16 May 2025 at 21:59, Nicolas Grekas
wrote:
>
>
>
> Le jeu. 15 mai 2025 à 16:06, Larry Garfield a écrit :
>>
>> On Thu, May 15, 2025, at 1:22 AM, Stephen Reay wrote:
>>
>> > I may be missing something here..
>> >
>> > So far the issues are "how do we deal with a parameter for the actual
>
On Thu, 15 May 2025 at 13:56, Stephen Reay wrote:
>
>
>
>
> > On 15 May 2025, at 16:44, Andreas Hennings wrote:
> >
> > On Thu, 15 May 2025 at 08:24, Stephen Reay
> > wrote:
> > [..]
> >>
> >>
> >> I may be missing so
On Thu, 15 May 2025 at 08:24, Stephen Reay wrote:
[..]
>
>
> I may be missing something here..
>
> So far the issues are "how do we deal with a parameter for the actual object,
> vs new properties to apply", "should __clone be called before or after the
> changes" and "this won't allow regular
On Sun, 27 Apr 2025 at 10:27, Rob Landers wrote:
>
> On Sun, Apr 27, 2025, at 10:16, Edmond Dantes wrote:
>
> Good afternoon, Larry.
>
> Looking at the comparison table, it seems that the two most important
> differences are:
>
> Backtrace consumes a lot of resources.
>
> There is an explicit con
On Tue, 22 Apr 2025 at 19:39, Gina P. Banyard wrote:
>
> Hello internals,
>
> The discussion about allowing never types as parameter types made me think
> about what problem it is truly trying to solve,
> which is using the same type as parameters and return values between multiple
> methods of
nstructor scope it would fail:
\Attribute::getOriginatingReflector(); // Throws RuntimeExeption, or a
dedicated exception type.
new MyAttribute(); // Throws RuntimeException or a dedicated exception type.
The exact behavior here can be discussed.
--- Andreas
On Tue, 30 May 2023 at 02:48, Andre
On Tue, 15 Apr 2025 at 20:59, Daniel Scherzer
wrote:
>
> On Tue, Apr 8, 2025 at 6:40 PM Daniel Scherzer
> wrote:
>>
>>
>> Since a lot of the discussion seems to be around static analysis and whether
>> there is a real use case for this, I wanted to share another use case I just
>> came across:
On Tue, 8 Apr 2025 at 18:38, Levi Morrison wrote:
>
> On Sat, Apr 5, 2025 at 9:51 AM Niels Dossche wrote:
> >
> > Hi internals
> >
> > I'm opening the discussion for the RFC "array_first() and array_last()".
> > https://wiki.php.net/rfc/array_first_last
> >
> > Kind regards
> > Niels
>
> I dislik
On Mon, 7 Apr 2025 at 02:48, Ayesh Karunaratne wrote:
>
> > On Mon, Apr 7, 2025 at 2:05 AM Bilge wrote:
> > ... [snip] I suggest first proving there is a
> > legitimate need.
>
> I did a quick GitHub search for a common pattern of accessing an array
> value by using the `array_key_first` and `arr
> I am pleased to present my first RFC: Static class
To recap my opinion from the other thread:
I generally support the idea to have a label to slap on all-static
classes, to make that contract more explicit.
The goal is not to promote a specific use of the language, but to add
clarity to what alr
On Sun, 23 Jun 2024 at 18:28, Larry Garfield wrote:
>
> On Thu, Jun 20, 2024, at 8:35 PM, Andreas Hennings wrote:
> >> Ilija and I have been working on and off on an RFC for pattern matching
> >> since the early work on Enumerations.
> >
> > I like what I se
> Ilija and I have been working on and off on an RFC for pattern matching since
> the early work on Enumerations.
I like what I see, a lot!
One quick thought that came to my mind, regarding objects:
Could we check method return values?
if ($x is Countable { count(): 0 }) ...
if ($p is Point { ge
On Sun, 16 Jun 2024 at 20:08, Rowan Tommins [IMSoP]
wrote:
>
> On 16/06/2024 18:54, Andreas Hennings wrote:
>
> Yes, the possibility for namespace part imports exists.
> Unfortunately these namespace imports usually need to be set up
> manually, whereas the regular class or f
On Sun, 16 Jun 2024 at 19:09, Rowan Tommins [IMSoP]
wrote:
>
> On 16/06/2024 16:24, Andreas Hennings wrote:
>
> For a function call, the namespace is usually only visible in the
> imports list at the top of the file.
>
>
> This is one of those interesting cases wher
On Sun, 16 Jun 2024 at 17:44, Larry Garfield wrote:
>
> On Sun, Jun 16, 2024, at 10:24 AM, Andreas Hennings wrote:
> > Regarding function autoloading:
> >
> > A more interesting question to me is a convention where to put each
> > function.
> > With classes,
Regarding function autoloading:
A more interesting question to me is a convention where to put each function.
With classes, PSR-4 tells us exactly what one can expect to find in a
class file with a given name.
Perhaps a separate directory tree per package, with one file per sub-namespace?
Or just
On Fri, 7 Jun 2024 at 21:17, Rob Landers wrote:
>
>
>
> On Fri, Jun 7, 2024, at 21:02, Andreas Hennings wrote:
>
> On Fri, 7 Jun 2024 at 20:31, Larry Garfield wrote:
> >
> > On Fri, Jun 7, 2024, at 5:56 PM, ericm...@php.net wrote:
> >
> > >> I
On Fri, 7 Jun 2024 at 20:31, Larry Garfield wrote:
>
> On Fri, Jun 7, 2024, at 5:56 PM, ericm...@php.net wrote:
>
> >> Instead of ~ (which reminds me of the pendulum of symbols to written to
> >> symbols and back again every 10ish years; “or” vs “||”), why not make a
> >> shorthand way to write
Hello Larry,
just a quick thought.
Is there a reason why we cannot just make it "public private string
$x" instead of "public private(set) string $x"?
We would define that the second visibility specifier is for write.
The current proposal with "public private(set)" is less ambiguous, and
it is imm
On Tue, 13 Jun 2023 at 22:13, Larry Garfield wrote:
>
> On Tue, Jun 13, 2023, at 3:51 PM, Máté Kocsis wrote:
> > Hi Larry,
> >
> > In this case, if the `with` happens first, then the new address object is
> >> cloned needlessly, but that *probably* doesn't hurt anything. But $newAddr
> >> !== $p3
Hello list,
to revive this old RFC.
One really nice application of never parameters is with intersection types:
interface I {}
interface ReturnI {
public function foo(never $x): I;
}
interface AcceptI {
public function foo(I $x): mixed;
}
function f(ReturnI&AcceptI $arg, I $x): I {
On Tue, 14 Nov 2023 at 18:49, Robert Landers wrote:
>
> On Tue, Nov 14, 2023 at 1:39 PM Andreas Hennings wrote:
> >
> > Hello Robert,
> >
> > On Tue, 14 Nov 2023 at 11:09, Robert Landers
> > wrote:
> > >
> > > Andreas,
> > >
>
On Tue, 14 Nov 2023 at 02:08, David Gebler wrote:
>
> On Sun, Nov 12, 2023 at 8:20 PM Andreas Hennings
> wrote:
>
> > So to me, this alone is an argument to implement this natively.
> > The other argument is that it is kind of sad how the current functions
> > do
Hello Robert,
On Tue, 14 Nov 2023 at 11:09, Robert Landers wrote:
>
> Andreas,
>
> Just out of curiosity, what is the use case for this? I can't really
> think of a practical case where strict checking is needed for these
> functions. Usually, you have a really good idea of what is in the
> array
On Sat, 11 Nov 2023 at 20:43, Andreas Hennings wrote:
>
> Hello David,
>
> On Sat, 11 Nov 2023 at 20:04, David Gebler wrote:
> >
> > On Sat, Nov 11, 2023 at 6:05 PM Andreas Hennings
> > wrote:
> >
> > > Hello internals,
> > > I noticed t
Hello David,
On Sat, 11 Nov 2023 at 20:04, David Gebler wrote:
>
> On Sat, Nov 11, 2023 at 6:05 PM Andreas Hennings
> wrote:
>
> > Hello internals,
> > I noticed that array functions like array_diff(), array_intersect()
> > etc use weak comparison.
> >
>
Hello internals,
I noticed that array functions like array_diff(), array_intersect()
etc use weak comparison.
E.g.
array_diff([0, '', false, null], [null])
only leaves [0].
This makes these functions useless for a number of applications.
Also it can lead to unpleasant surprises, if a developer is
Hello Ilija,
On Sat, 17 Jun 2023 at 13:27, Ilija Tovilo wrote:
>
> Hi Andreas
>
> On Fri, Jun 16, 2023 at 9:23 PM Andreas Hennings wrote:
> >
> > Hello list,
> > I don't know if something like this was already proposed in the past,
> > I did not find any
Hello Rowan, Ilja,
(sorry I did not see these replies sooner, I do some forwarding but it failed)
On Sat, 17 Jun 2023 at 16:59, Rowan Tommins wrote:
>
> On 17/06/2023 12:26, Ilija Tovilo wrote:
> > I don't believe blocks for general expressions are that useful in PHP
> > due to the lack of block
Hello list,
I don't know if something like this was already proposed in the past,
I did not find anything.
Sometimes it would be nice to have a code block inside an expression, like this:
public function f(string $key) {
return $this->cache[$key] ??= {
// Calculate a value for $key.
On Tue, 30 May 2023 at 22:45, Larry Garfield wrote:
>
> On Tue, May 30, 2023, at 7:34 PM, Andreas Hennings wrote:
> > On Tue, 30 May 2023 at 19:12, Larry Garfield wrote:
> >>
> >> I've run into this issue in my attribute library as well
> >> (https://
On Tue, 30 May 2023 at 19:12, Larry Garfield wrote:
>
> I've run into this issue in my attribute library as well
> (https://github.com/Crell/AttributeUtils). What I do there is allow
> attributes to opt-in to a callback method via interface. For example:
>
> #[\Attribute]
> class AttribWithNam
On Tue, 30 May 2023 at 18:48, Larry Garfield wrote:
>
>
>
> --
> Larry Garfield
> la...@garfieldtech.com
>
> On Tue, May 30, 2023, at 2:42 AM, Andreas Hennings wrote:
> > Hello list,
> > this proposal will be useful in combination with "Declaration-a
0d96abd933b9f03b310#file-test_array_group-php
> >> 3. Another example, addressing the problem of increasing subsequences is
> >> very simple with `array_group`:
> >> https://gist.github.com/bor0/b5f449bfe85440d96abd933b9f03b310#file-test_array_incr_subseqs-php
> &
$group = [];
}
$group[] = $value;
$prev = $value;
}
if ($group) {
$groups[] = $group;
}
return $groups;
}
On Tue, 30 May 2023 at 18:21, Andreas Hennings wrote:
>
> Thank you, this clarifies and it confirms my initial assumption of
> what you are proposi
equences is very
> simple with `array_group`:
> https://gist.github.com/bor0/b5f449bfe85440d96abd933b9f03b310#file-test_array_incr_subseqs-php
>
> Best,
>
> Boro
>
> > On 30.5.2023, at 16:57, Andreas Hennings wrote:
> >
> > Hello Boro,
> > I think you sho
Hello Boro,
I think you should include the "expected result" in your code examples.
Maybe this is in your patch file, but I don't think we want to look at
that for discussion.
Cheers
Andreas
On Tue, 30 May 2023 at 13:35, Boro Sitnikovski wrote:
>
> Hello all,
>
> As per the How To Create an RFC
On Tue, 30 May 2023 at 15:14, Stephen Reay wrote:
>
> (Resending to the list without all the history because qmail complained about
> message size)
>
>
> >>
> >> Hi Andreas,
> >>
> >> I too have wondered (and I think asked in room11?) about such a concept.
> >> >From memory the general response
On Tue, 30 May 2023 at 05:22, Stephen Reay wrote:
>
>
>
> > On 30 May 2023, at 07:48, Andreas Hennings wrote:
> >
> > Hello internals,
> > I am picking up an idea that was mentioned by Benjamin Eberlei in the past.
> > https://externals.io/message/1102
Hello list,
this proposal will be useful in combination with "Declaration-aware attributes"
Problem
Currently, ReflectionMethod is not aware of the original class, if the
method is declared in a parent class.
Methods that are called during a discovery algorithm that need to
process a met
I just notice a flaw in my thinking.
On Tue, 30 May 2023 at 02:48, Andreas Hennings wrote:
>
> Note that for methods, we typically need to know the method reflector
> _and_ the class reflector, because the method could be defined in a
> base class.
This is true when doing a dis
Thanks for the feedback!
On Tue, 30 May 2023 at 03:43, Dusk wrote:
>
> On May 29, 2023, at 17:48, Andreas Hennings wrote:
> > Quite often I found myself writing attribute classes that need to fill
> > some default values or do some validation based on the symbol the
> >
public readonly string $y,
) {}
}
On Tue, 30 May 2023 at 02:48, Andreas Hennings wrote:
>
> Hello internals,
> I am picking up an idea that was mentioned by Benjamin Eberlei in the past.
> https://externals.io/message/110217#110395
> (we probably had the idea independently, bu
Hello internals,
I am picking up an idea that was mentioned by Benjamin Eberlei in the past.
https://externals.io/message/110217#110395
(we probably had the idea independently, but Benjamin's is the first
post where I see it mentioned in the list)
Quite often I found myself writing attribute class
On Tue, 18 Apr 2023 at 22:01, Bob Magic wrote:
>
> > [1] In fact if the right hand side of with may be an expression that
> > evaluates to an array, folks wouldn't need to learn new syntax at all:
> >
> > $newProperties = [ "foo" => "bar" ];
> > clone $object with $newProperties;
> >
> > a
> The biggest advantage of Nicolas' proposal over “clone with” is that it could
> be made part of the interface contract whether a method modifies the object
> state. So the PSR-7 ResponseInterface could look like the following:
> [..]
> public clone function withStatus($code, $reasonPhrase = '')
Hello Máté, internals,
I have been waiting for this to happen :)
Some feedback
> However, in some cases it would be useful to reference property names as
> expressions, e.g. when one needs to use “clone with” in a foreach loop where
> the index is the property name and the loop variable is the v
> I have the feeling I'm missing something, but how would this compare to
array join
Array join does neither append nor replace if a numeric index already exists.
But you can do [...$arr0, ...$arr1].
https://3v4l.org/CIinR
print json_encode([
[...['a', 'b'], ...['c', 'd']], // [a, b, c, d]
Hello,
the RFC seems like a good idea to me.
However, I do not see any mention of plus operator on arrays, e.g. ['a' =>
'A'] + ['b' => 'B']. The array_reduce() would support this, but I think
array_sum() would not, because of the return type. I just think this should
be made more explicit.
-- Andre
On Thu, 21 Apr 2022 at 11:18, Rowan Tommins wrote:
>
> On Wed, 20 Apr 2022 at 19:16, Claude Pache wrote:
>
> > > You make a very important claim in your bug report:
> > >
> > > > However, in real world, is_callable() is almost never given totally
> > arbitrary stuff
> > >
> > > My concern is that
A deprecation warning on is_callable() would imply that in a future
version of PHP that call will be illegal.
But this is not the case.
is_callable() is meant to accept any value, and return true or false.
is_callable('static::method') will still be a valid call in future
versions, only the result
> sketch out a more complete picture for the type
system. We can implement it in pieces and parts, but we should have a goal
in mind for where we want to land.
I think the type system in psalm is pretty cool. It does have fixed
literal values, but also deeply structured array types.
But:
- I don'
Hello list.
Another potential benefit of such interfaces can be polyfills.
PHP 8.x: class ReflectionClass implements Reflector, AttributesHaving {..}
PHP 7.x. class UserlandReflectionClass extends ReflectionClass
implements AttributesHaving {..}
function f(AttributesHaving $reflector) {
$attrib
On Tue, 1 Mar 2022 at 21:03, DANIEL VARGAS MUCCILLO
wrote:
>
> >
> > I *think* all Reflector children support attributes, so it may not need a
> > separate interface.
>
>
> ReflectionZendExtension and ReflectionExtension are currently the only ones
> who implement Reflector but don't support attr
opaganda.
And to anybody who is afraid of some disruption and debate in this mailing list:
Think of the disruption it would cause if your house gets bombed, the
freedom in your country is threatened, your family has to flee the
country.
-- Andreas Hennings
>
>
> > I have put somethin
On Thu, 13 Jan 2022 at 15:36, Andreas Hennings wrote:
>
> Hello list,
> I want to bring up a topic that has bothered me whenever I use traits.
> I don't have a solution proposal for it, yet, unfortunately.
> I was going to comment in the other thread about traits, but it seems
Hello list,
I want to bring up a topic that has bothered me whenever I use traits.
I don't have a solution proposal for it, yet, unfortunately.
I was going to comment in the other thread about traits, but it seems
better suited for a new discussion.
--
Traits allow to share code between c
On Wed, 5 Jan 2022 at 20:11, Jordan LeDoux wrote:
>
>
>
> On Wed, Jan 5, 2022 at 6:33 AM Andreas Hennings wrote:
>>
>> Hello Jordan,
>> do you have any thoughts about these symmetric/left/right modifiers,
>> to get rid of the $operandPos parameter?
>>
&g
of the RFC?
Cheers
Andreas
On Tue, 4 Jan 2022 at 00:27, Andreas Hennings wrote:
>
> Hello Jordan,
>
> I have another note about the RFC.
> (I am not sure what's the policy, if we should continue _all_
> discussion here or go back to the RFC thread. Hope it's ok here.)
On Tue, 4 Jan 2022 at 03:23, Jordan LeDoux wrote:
>
>
>
> On Mon, Jan 3, 2022 at 4:05 PM Andreas Hennings wrote:
>>
>> To me it is not surprising that an RFC like this would be controversial.
>> We could enter a wonderful new era of value objects with operators,
On Mon, 3 Jan 2022 at 22:15, Jordan LeDoux wrote:
>
> On Mon, Jan 3, 2022 at 9:07 AM Pierre wrote:
>
> > I forgot to answer to that, specifically. I'd much more prefer to have
> > an explicit `equals(object $other): bool` (magic or not, really I do not
> > care) single method for equality only, t
Hello Jordan,
I have another note about the RFC.
(I am not sure what's the policy, if we should continue _all_
discussion here or go back to the RFC thread. Hope it's ok here.)
OperandPosition::LeftSide
OperandPosition::RightSide
I wonder if this is the best way to model this.
Especially, it doe
On Mon, 3 Jan 2022 at 16:00, Marco Pivetta wrote:
>
> Hey Andreas,
>
> On Mon, Jan 3, 2022 at 3:40 PM Andreas Hennings wrote:
>>
>> I imagine that operator overloads can improve DX for these use cases,
>> but at a cost for the overall language.
>>
>&g
One question that just occured to me:
Why allow the "public" keyword for visibility, if operators are public
automatically, and "private" and "protected" are not allowed?
Do we plan for private/protected operators in the future?
Shouldn't we eliminate meaningless choice?
On Mon, 3 Jan 2022 at 01:1
On Mon, 3 Jan 2022 at 02:07, Marco Pivetta wrote:
>
> Hey Jordan,
>
> I've voted "no" on this one: infix functions may have been interesting, but
> adding a whole new type system around operators is really not worth it,
> given:
>
> * Added AST nodes
> * Added method definitions for niche use-ca
On Sun, 2 Jan 2022 at 06:20, Michael Morris wrote:
>
> On Sat, Jan 1, 2022 at 10:47 PM Kirill Nesmeyanov wrote:
>
> >
> > >Суббота, 1 января 2022, 17:41 +03:00 от Rowan Tommins <
> > rowan.coll...@gmail.com>:
> > >
> > >On 31/12/2021 00:21, Kirill Nesmeyanov wrote:
> > >> I support this behavior
On Tue, 21 Dec 2021 at 23:20, Jordan LeDoux wrote:
>
>
>
> On Tue, Dec 21, 2021 at 5:47 AM Andreas Hennings wrote:
>>
>> I see the "Implied Operators" section.
>> I assume this means that a new instance will be created, and stored on
>> the same vari
On Tue, 21 Dec 2021 at 02:57, Jordan LeDoux wrote:
>
>
>
> On Mon, Dec 20, 2021 at 4:43 PM Andreas Hennings wrote:
>>
>> > The exact position of where that trade-off is 'worth it' is going to
>> > be different for different people. But one of the are
On Tue, 21 Dec 2021 at 10:13, Rowan Tommins wrote:
>
> On 21/12/2021 00:43, Andreas Hennings wrote:
> > I think the example in the RFC is interesting, but not ideal to
> > advertise the RFC.
> > The example is with native scalar types and build-in operator
> > impl
On Tue, 21 Dec 2021 at 00:03, Dan Ackroyd wrote:
>
> On Fri, 17 Dec 2021 at 18:36, Stanislav Malyshev wrote:
> >
> > When reading
> > this code: $foo * $bar - how do I know which of the ways you took and
> > where should I look for the code that is responsible for it? When I see
> > $foo->times($
On Fri, 17 Dec 2021 at 00:25, Larry Garfield wrote:
>
> On Thu, Dec 16, 2021, at 1:24 PM, Andreas Hennings wrote:
>
> > I see the distinction in overloading based on the object type on the
> > left, vs overloading based on parameter types.
> >
> > For a method c
On Thu, 16 Dec 2021 at 19:20, Dan Ackroyd wrote:
>
> On Thu, 16 Dec 2021 at 12:21, Andreas Hennings wrote:
>
> > Methods and functions have searchable and clickable names. Operators don't.
> > The "searchable" applies to grep searches in code, but also google
Hello internals,
some concerns I have about operator overloading.
(I have seen and played with operator overloading long time ago in
C++, this is my background for these points.)
1. Searchable names.
Methods and functions have searchable and clickable names. Operators don't.
The "searchable"
Oct 2021 at 08:18, Andreas Hennings wrote:
>
> On Sat, 2 Oct 2021 at 16:37, tyson andre wrote:
> >
> > Hi Andreas,
> >
> > > Hello list,
> > > I would like to propose new methods for ReflectionType, that would
> > > allow treating ReflectionNamed
On Sun, 3 Oct 2021 at 07:40, Sebastian Bergmann wrote:
>
> Am 02.10.2021 um 16:37 schrieb tyson andre:
> > `ReflectionType->allowsValue(mixed $value, bool $strict = true): bool`
>
> Not having to implement and maintain that functionality in userland would
> be brilliant and much appreciated. Right
On Sat, 2 Oct 2021 at 16:37, tyson andre wrote:
>
> Hi Andreas,
>
> > Hello list,
> > I would like to propose new methods for ReflectionType, that would
> > allow treating ReflectionNamedType and ReflectionUnionType in a
> > unified way.
> > This would eliminate the need for if (.. instanceof) in
Hello list,
I would like to propose new methods for ReflectionType, that would
allow treating ReflectionNamedType and ReflectionUnionType in a
unified way.
This would eliminate the need for if (.. instanceof) in many use cases.
Some details can still be discussed, e.g. whether 'null' should be
inc
Hello Levi,
I thought it was clear.
By static "factory" method I just mean any static method that returns an object.
Don't interpret too much into the term :)
So to clarify, here is an example:
class OtherAttribute {}
class MyAttribute {
public function __construct(string $name) {..}
#[Attr
Hello list,
currently, the default mode for attributes is to create a new class.
For general initializers, with
https://wiki.php.net/rfc/new_in_initializers we get the option to call
'new C()' for parameter default values, attribute arguments, etc.
Personally I find class construction to be limit
On Sat, 14 Aug 2021 at 15:05, Larry Garfield wrote:
>
> On Sat, Aug 14, 2021, at 7:48 AM, 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
On Wed, 8 Sept 2021 at 23:00, Rowan Tommins wrote:
>
> On 08/09/2021 16:37, Mike Schinkel wrote:
>
> > All future code that needs to refer to the class name will still refer to
> > `stdClass`, so we won't be gaining much by creating an alias.
>
>
> Just to be clear, the only code that would need
here is a hard-coded internal implementation when calling
json_encode() or converting to array.
https://3v4l.org/rAc4K
I think we would want something more clean and transparent.
On Wed, 8 Sept 2021 at 21:58, Andreas Hennings wrote:
>
> On Wed, 8 Sept 2021 at 18:33, Lynn wrote:
> &
On Wed, 8 Sept 2021 at 18:33, Lynn wrote:
>
> On Wed, Sep 8, 2021 at 5:38 PM Mike Schinkel wrote:
>
> > A couple more things; add a `JSON_OUTPUT_DYNAMIC_OBJECT` flag to output to
> > DynamicObject for `json_decode()`, add a 3rd parameter for flags to
> > var_export() for the same reason, a `'ret
$source['a0']['b01'] = 5;On Wed, 8 Sept 2021 at 16:48, Andreas
Hennings wrote:
>
> On Wed, 8 Sept 2021 at 16:10, Andreas Hennings wrote:
> >
> > Thanks for the feedback so far!
> >
> > On Wed, 8 Sept 2021 at 10:13, Marco Pivetta wrote:
>
On Wed, 8 Sept 2021 at 16:10, Andreas Hennings wrote:
>
> Thanks for the feedback so far!
>
> On Wed, 8 Sept 2021 at 10:13, Marco Pivetta wrote:
> >
> > Heyo,
> >
> > On Wed, 8 Sep 2021, 02:19 Andreas Hennings, wrote:
> >>
> >> Hello int
Thanks for the feedback so far!
On Wed, 8 Sept 2021 at 10:13, Marco Pivetta wrote:
>
> Heyo,
>
> On Wed, 8 Sep 2021, 02:19 Andreas Hennings, wrote:
>>
>> Hello internals,
>>
>> The function array_column() would be much more useful if there was an
>>
1 - 100 of 232 matches
Mail list logo
