Hi Larry and Nicolas,
On Wed, Mar 25, 2020 at 9:24 AM Larry Garfield wrote:
> > I'd like to propose something on the topic.
> > I'm adding object literals to the mix because that's another feature of the
> > language that we're missing a lot IMHO.
> > Actually, there is one existing syntax for
Am 25.03.20 um 15:24 schrieb Larry Garfield:
> On Wed, Mar 25, 2020, at 5:57 AM, Nicolas Grekas wrote:
>> Máté suggested this syntax and it has my preference over the one you menton
>> Larry: doubling the visibility keyword could be enough to express
>> read+write access:
>>
>> public private
On Wed, Mar 25, 2020, at 5:57 AM, Nicolas Grekas wrote:
> > > https://hive.blog/php/@crell/improving-php-s-object-ergonomics
> > Named parameters are a pretty tough topic. I think one of the main points
> > of contention is that they make the parameters names part of the API
> > contract, and as
> > https://hive.blog/php/@crell/improving-php-s-object-ergonomics
Thanks Larry, that's a good way to move forward on these topics.
I generally like the ideal of combining property declaration and
> constructors. I've had this on my mind for a while already, and also
> received the same
>
> For details, see the full writeup:
>
> https://hive.blog/php/@crell/improving-php-s-object-ergonomics
An excellent writeup, thank you Larry.
Peter
On 24-03-2020 10:21, Máté Kocsis wrote:
> Hi Larry,
>
> In my opinion, one of the core assets of PHP is that it contains relatively
> few syntactic sugar compared
> to some other languages, e.g. C#. Maybe it's just me, but I believe it
> makes the code written in PHP
> easier to read. And I think
>
> If the answer to that is "well don't do that", then what's the
> alternative? PHP offers no other syntax for evolvable immutable objects
> than private properties with Wither methods. Making Wither methods harder
> makes evolvable immutable objects harder. Unless there's some entirely
>
On Tue, Mar 24, 2020, at 6:52 AM, Nikita Popov wrote:
> On Mon, Mar 23, 2020 at 1:48 AM Larry Garfield
> Thanks for the write-up Larry. I like where you're going with this.
>
> If we were starting from a blank slate design, I would advocate for:
>
> a) having an object initializer syntax
> b)
On Mon, Mar 23, 2020 at 1:48 AM Larry Garfield
wrote:
> Hi folks.
>
> There have been a lot of RFCs and possible RFCs of late that are all
> circling around the same related problem space: Working with objects right
> now involves too much boilerplate to get things done. As I've mentioned
>
Hi Larry,
In my opinion, one of the core assets of PHP is that it contains relatively
few syntactic sugar compared
to some other languages, e.g. C#. Maybe it's just me, but I believe it
makes the code written in PHP
easier to read. And I think this is what we should optimize for. Not for
saving a
On Mon, Mar 23, 2020, at 2:47 PM, Michał Brzuchalski wrote:
> Hi Larry,
> > The value here is combining constructor promotion with named parameters.
> > Constructor promotion itself is useful for the class implementer, but
> > doesn't help the caller. Named parameters helps the caller, but
Hi Larry,
pon., 23 mar 2020 o 20:04 Larry Garfield
napisał(a):
> Merging some replies together here...
>
> On Sun, Mar 22, 2020, at 8:36 PM, Levi Morrison via internals wrote:
> > > In short: I believe our biggest potential win is to focus on 3 RFCs:
> > >
> > > * Constructor Promotion
> > I
Merging some replies together here...
On Sun, Mar 22, 2020, at 8:36 PM, Levi Morrison via internals wrote:
> > In short: I believe our biggest potential win is to focus on 3 RFCs:
> >
> > * Constructor Promotion
> I would vote yes on this, assuming the implementation is sane.
On Mon, Mar 23,
> On Mar 22, 2020, at 8:47 PM, Larry Garfield wrote:
> https://hive.blog/php/@crell/improving-php-s-object-ergonomics
Hi Larry,
That is a really excellent writeup. Thanks from me at least for taking the
time to write it up in depth.
Looking at your conclusion, my gut feelings tell me your
Hi Larry,
pon., 23 mar 2020, 01:48 użytkownik Larry Garfield
napisał:
> Hi folks.
>
> There have been a lot of RFCs and possible RFCs of late that are all
> circling around the same related problem space: Working with objects right
> now involves too much boilerplate to get things done. As
> In short: I believe our biggest potential win is to focus on 3 RFCs:
>
> * Constructor Promotion
I would vote yes on this, assuming the implementation is sane.
> * Named parameters
This one is tricky -- there are tradeoffs of every approach I've seen
proposed. I have an idea for another way to
16 matches
Mail list logo
