Hey everyone.
Any news on this? I'm really excited about this one. =)
--
Erick de Azevedo Lima
Em ter., 30 de mai. de 2023 às 14:15, Larry Garfield
escreveu:
>
>
> --
> Larry Garfield
> la...@garfieldtech.com
>
> On Mon, May 29, 2023, at 8:28 PM, Claude Pache wrote:
> >> Le 8 mai 2023 à
--
Larry Garfield
la...@garfieldtech.com
On Mon, May 29, 2023, at 8:28 PM, Claude Pache wrote:
>> Le 8 mai 2023 à 23:38, Larry Garfield a écrit :
>>
>> Ilija Tovilo and I would like to offer another RFC for your consideration.
>> It's been a while in coming, and we've evolved the
> Le 8 mai 2023 à 23:38, Larry Garfield a écrit :
>
> Ilija Tovilo and I would like to offer another RFC for your consideration.
> It's been a while in coming, and we've evolved the design quite a bit just in
> the last week so if you saw an earlier draft of it in the past few months, I
>
I can't wait!
Especially because I'm heading a modernization of the systems in my
organization and my plan is to use the cutting edge PHP version for it.
Currently our internal "framework" uses PHP 7.4, but with a PHP 5.6 coding
style.
Again: I can't wait!
I can't do much but thank everyone who
On Mon, May 8, 2023, at 9:38 PM, Larry Garfield wrote:
> Ilija Tovilo and I would like to offer another RFC for your
> consideration. It's been a while in coming, and we've evolved the
> design quite a bit just in the last week so if you saw an earlier draft
> of it in the past few months, I
> Secondary votes are generally discouraged. I can see the argument for
> wanting a short-short version of set, given how common the validation use
> case is, but => is almost universally the "evaluates to" symbol, so using
> that for a set operation rather than get just feels weirdly
On Mon, May 15, 2023, at 8:12 PM, Hendra Gunawan wrote:
>> For the second, the problem with omitting the {} is that it creates yet
>> another syntax variant. That makes it harder for the parser, for static
>> analyzers, for user-space parsing tools like php-parser, etc. That's more
>> work
> (Also, when replying, please please remove duplicate names from the to/cc
> line. I just got double copies of everything in this thread this morning.
> I'm on the list, I don't need to be CCed.)
Sorry about that. Not my habit before.
> For the second, the problem with omitting the {} is
On Mon, May 15, 2023, at 8:32 AM, Lynn wrote:
> It's starting to get crowded in object constructors. The following example
> is so much more readable and maintainable imo. Would it be possible to
> still add the quick assignment as a language feature? I'm personally not
> happy having property
Missed one...
On Mon, May 15, 2023, at 8:14 AM, Hendra Gunawan wrote:
> Can the engine detect these logical errors?
> ```
> public string $fullName = "hendra gunawan" => $this->first . " " .
> $this->last;
>
> // or with my proposal:
> public string $fullName = "hendra gunawan" get =>
Consolidating all replies into a single message. Please try to keep them
together so it's easier to respond to.
(Also, when replying, please please remove duplicate names from the to/cc line.
I just got double copies of everything in this thread this morning. I'm on
the list, I don't need
> If there is no forward compatibility consideration, can we simplify
> interface definition to this one?
> ```
> interface IFace
> {
> public string $readable;
> public string $writeable;
> public string $both;
> }
> ```
After carefully reading the proposal again, I think I know the answer
> ```php
> class User {
> private string $first;
> private string $last;
> public string $fullName {
> get => $this->first . ' ' . $this->last;
> set => [$this->first, $this->last] = explode(' ', $value, 2);
> }
>
> public function __construct($this->fullName)
On Mon, May 15, 2023 at 1:41 AM Hendra Gunawan
wrote:
> 2. The shorthand notations supported (the shortest one) creates
> impaired syntax, and not pretty to look at for constructor property
> promotion.
>
It's starting to get crowded in object constructors. The following example
is so much more
On Tue, May 9, 2023 at 4:38 AM Larry Garfield wrote:
>
> Ilija Tovilo and I would like to offer another RFC for your consideration.
> It's been a while in coming, and we've evolved the design quite a bit just in
> the last week so if you saw an earlier draft of it in the past few months, I
>
On Tue, May 9, 2023 at 4:38 AM Larry Garfield wrote:
>
> Ilija Tovilo and I would like to offer another RFC for your consideration.
> It's been a while in coming, and we've evolved the design quite a bit just in
> the last week so if you saw an earlier draft of it in the past few months, I
>
On Tue, May 9, 2023 at 4:38 AM Larry Garfield wrote:
>
> Ilija Tovilo and I would like to offer another RFC for your consideration.
> It's been a while in coming, and we've evolved the design quite a bit just in
> the last week so if you saw an earlier draft of it in the past few months, I
>
On Tue, May 9, 2023 at 4:38 AM Larry Garfield wrote:
>
> Ilija Tovilo and I would like to offer another RFC for your consideration.
> It's been a while in coming, and we've evolved the design quite a bit just in
> the last week so if you saw an earlier draft of it in the past few months, I
>
>
> Regarding $field vs. $this->propName, there's a few reasons we went that
> route.
Overall I think this is a really good proposal, but you might want to
consider a second vote for that particular syntax.
`$field` vs `$this->propName` feels a little magical. It's a simpler magic
than actual
On Wed, May 10, 2023, at 11:35 AM, Robert Landers wrote:
>> Regarding $field vs. $this->propName, there's a few reasons we went that
>> route.
>>
>> 1. It's shorter and less typing for what will be a common pattern.
>> 2. That makes it consistent between hook implementations. In working on
>>
> Regarding $field vs. $this->propName, there's a few reasons we went that
> route.
>
> 1. It's shorter and less typing for what will be a common pattern.
> 2. That makes it consistent between hook implementations. In working on
> examples, I found many cases where I was adding basically the
On Tue, May 9, 2023, at 5:46 PM, Larry Garfield wrote:
>> I have a bigger concern: the take on references contradicts with the intro
>> about BC breaks: turning a materialized property into virtual one would
>> break BC as far as refs are concerned. One idea to fix that: add a ref
>> hook, that
On Mon, May 8, 2023, at 9:38 PM, Larry Garfield wrote:
> Ilija Tovilo and I would like to offer another RFC for your
> consideration. It's been a while in coming, and we've evolved the
> design quite a bit just in the last week so if you saw an earlier draft
> of it in the past few months, I
> Ilija Tovilo and I would like to offer another RFC for your consideration.
> It's
> been a while in coming, and we've evolved the design quite a bit just in the
> last
> week so if you saw an earlier draft of it in the past few months, I would
> encourage you to read it over again to make
It looks great!
Thank you so, so much. I've been wanting this for a long time. I have used
properties in C# and it's very useful. I'm reading this RFC since it was in
draft. =)
One thing that I did not understand was this piece of code:
class C {
public array $_names;
public string
On Mon, May 8, 2023 at 11:38 PM Larry Garfield
wrote:
> Ilija Tovilo and I would like to offer another RFC for your
> consideration. It's been a while in coming, and we've evolved the design
> quite a bit just in the last week so if you saw an earlier draft of it in
> the past few months, I
On 08-05-2023 23:38, Larry Garfield wrote:
Ilija Tovilo and I would like to offer another RFC for your consideration.
It's been a while in coming, and we've evolved the design quite a bit just in
the last week so if you saw an earlier draft of it in the past few months, I
would encourage
Ilija Tovilo and I would like to offer another RFC for your consideration.
> It's been a while in coming, and we've evolved the design quite a bit just
> in the last week so if you saw an earlier draft of it in the past few
> months, I would encourage you to read it over again to make sure we're
Hi
On 5/8/23 23:38, Larry Garfield wrote:
Ilija Tovilo and I would like to offer another RFC for your consideration.
It's been a while in coming, and we've evolved the design quite a bit just in
the last week so if you saw an earlier draft of it in the past few months, I
would encourage you
Hi Larry,
pon., 8 maj 2023 o 23:38 Larry Garfield napisał(a):
> Ilija Tovilo and I would like to offer another RFC for your
> consideration. It's been a while in coming, and we've evolved the design
> quite a bit just in the last week so if you saw an earlier draft of it in
> the past few
30 matches
Mail list logo
