On Wed, Mar 15, 2023 at 1:09 AM Rowan Tommins
wrote:
> On 14/03/2023 22:54, Larry Garfield wrote:
>
> Well, a large part of my resistance to automatic capture is that it
> makes variable scope less visible at a glance. This avoids that by still
> having a marker for "I am from another scope", but
On Tue, Mar 14, 2023 at 7:09 PM Rowan Tommins wrote:
> Outside of
> those cases, though, there's no reason it should mean anything, just as
> $this->foo or self::$foo doesn't mean anything outside a class. In fact,
> it could be spelled capture::$foo or $scope->foo rather than just using
> new pun
On 14/03/2023 22:54, Larry Garfield wrote:
However, I agree with Ilija that the original proposal to just do it
automatically would be better; and if that didn't pass, I have no expectation
that an alternate with a funky new syntax would do any better.
Well, a large part of my resistance to
> I guess you'd have to generate a new class entry every time the "new
> class" line was run, and inject the extra values into that.
>
>
> If it was limited to capturing scalars and arrays, you could treat it as
> a kind of macro expansion, i.e. this ...
>
> $example = new class {
> public $in
On Tue, Mar 14, 2023, at 3:41 PM, Rowan Tommins wrote:
> Hi all,
>
> I have been pondering for a while how to improve the anonymous class
> syntax to allow "capturing" of values from the outer scope, and came up
> with the idea of a special variable marker for "lexically captured
> variable" - i
On 14/03/2023 21:23, Ilija Tovilo wrote:
One thing to note is that, as I've learned recently, anonymous classes
can actually be instantiated at a later point with some tricks.
https://3v4l.org/2OcmP
Huh, that's freaky... I guess this is all a reminder that these really
are anonymous *classes
Hi
> This comment is very, very unnecessary. The message sent to the new
> potential maintainers by the outcome of the whole discussion is not very
> promising and such cheap irony doesn't help neither. I hope that at least
> PHP internals community can learn how to handle such cooperation problem
Hey Rowan
On Tue, Mar 14, 2023 at 9:41 PM Rowan Tommins wrote:
>
> Hi all,
>
> I have been pondering for a while how to improve the anonymous class
> syntax to allow "capturing" of values from the outer scope, and came up
> with the idea of a special variable marker for "lexically captured
> vari
Hi all,
I have been pondering for a while how to improve the anonymous class
syntax to allow "capturing" of values from the outer scope, and came up
with the idea of a special variable marker for "lexically captured
variable" - instead of $foo, you would write $!foo or $^foo (I quite
like the
> Seems Uncle Bob with his boy scout rule left the room...
This comment is very, very unnecessary. The message sent to the new
potential maintainers by the outcome of the whole discussion is not very
promising and such cheap irony doesn't help neither. I hope that at least
PHP internals community
On Tue, Mar 14, 2023, at 8:50 AM, Robert Landers wrote:
> On Tue, Mar 14, 2023 at 1:57 PM Rowan Tommins wrote:
>>
>> On Tue, 14 Mar 2023 at 10:39, Bob Weinand wrote:
>>
>> > Hey Rowan,
>> >
>> > do we actually need *positional* partial application, after a ... token?
>> >
>> > Would it not be eno
On Tue, Mar 14, 2023 at 1:57 PM Rowan Tommins wrote:
>
> On Tue, 14 Mar 2023 at 10:39, Bob Weinand wrote:
>
> > Hey Rowan,
> >
> > do we actually need *positional* partial application, after a ... token?
> >
> > Would it not be enough, to simply forbid positional arguments after a ...
> > and jus
On Tue, 14 Mar 2023 at 10:39, Bob Weinand wrote:
> Hey Rowan,
>
> do we actually need *positional* partial application, after a ... token?
>
> Would it not be enough, to simply forbid positional arguments after a ...
> and just allow named arguments? These already have well defined position
> ind
> Am 14.03.2023 um 10:16 schrieb Rowan Tommins :
>
> On 13/03/2023 20:44, Larry Garfield wrote:
>> As has been discussed numerous times, all of the most used array functions
>> need to be redesigned to work with iterables, and in many cases make more
>> sense. That would be a natural time to
On 13/03/2023 20:44, Larry Garfield wrote:
As has been discussed numerous times, all of the most used array functions need
to be redesigned to work with iterables, and in many cases make more sense.
That would be a natural time to also revisit parameter order to fit with
whatever partial appl
15 matches
Mail list logo
