Re: [PHP-DEV] [RFC] Partial function application

[Alexandru Pătrănescu]

Hi Larry,

On Tue, May 11, 2021 at 8:55 PM Larry Garfield 
wrote:

>
> They currently do, since they work by creating a Closure-esque object
> called Partial with an __invoke() method.
>
> --Larry Garfield
>
>
1. Would it be possible to mention the `Partial` class in the RFC? From
what I understand this is what it will be returned by the
`get_class($partial)`.
I guess the class will be final (similar with Closure) and will only have a
private constructor and a public __invoke method.

2. As now ReflectionFunction accepts Closure|string, wouldn't it be simpler
for the users to just have it accept Closure|Partial|string to avoid
introducing another reflection class and also avoid the userland issue you
mentioned?

Alex

Re: [PHP-DEV] Discussion: Object-scoped RNG

[Larry Garfield]

On Tue, May 11, 2021, at 7:57 AM, Go Kudo wrote:
> Hi internals.
> 
> I previously proposed an object scope RNG implementation inside.
> However, the RFC was rejected after a vote.
> 
> https://wiki.php.net/rfc/object_scope_prng
> 
> Vote: https://externals.io/message/113888
> Discussion: https://externals.io/message/112819
> 
> As per my previous proposal, PHP is currently in a very unclear state
> regarding the random number implementation.
> 
> So I would like to ask a few questions.
> 
> - Do you think that PHP needs an object-scoped random number
> implementation? And why?

I don't work in areas that would tend to need such a thing, but other people do 
so I have no objection to it existing, as long as it's well-designed.

> - If the API in the previous RFC was improved and voted on again, would you
> be willing to vote for it?

Yes.

> - What issues do you think should have been resolved between proposal and
> ballot in the previous RFC?
> 
> I would like a variety of opinions.

1) Get rid of all of the functions.  Object-scoped means... you just have an 
object with methods on it.  That's it.

2) Don't force people to use a subclass with an incomprehensible name.  In this 
case, a single class with a constructor parameter that specifies the algorithm 
to use is far superior.  Possibly that parameter could be an object conforming 
to an interface if you really want, as long as the default is reasonable so 
most people never have to use it.

3) Perhaps it should be named RandomSequence or similar?  It's not truly 
generating random numbers.  It's generating a repeatable but difficult to 
produce sequence off of a seed value.  That's not the same thing as 
random_int() et al.

So, at first pass, an API could be as simple as (pseudocode):

class RandomSequence {
  public function __construct(int $seed = time(), $algorithm = 'some_default') 
{ ... }

  public function next(): int { ... }
}

And that's it.  That's nice and simple and predictable to use.

4) As Levi said, we have a new policy document on namespace usage.  This is a 
good first application of it.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Christoph M. Becker]

On 11.05.2021 at 18:58, Kamil Tekiela wrote:

> On 11.05.2021 at 18:44, Peter Bowyer wrote:
>
>> I doubt "bottom posting" is a term people who started online in the
>> last 10 years know - with today/yesterday's example, my takeaway was
>> the original poster didn't know what it meant.
>
> Yeah, the first time I heard about it is on this mailing list. I didn't
> know it was a thing before, and I admit I might still not understand why it
> is a thing. […]

Bottom posting is nonsense.  It is actually about posting comments
inline, i.e. right below the context (a sentence, paragraph, etc.)
you're referring to.  And it's about snipping content which is
irrelevant to your reply (of course that could be misused to rip parts
of former replies out of context, but that should be avoided).

Just read this message in a few weeks.  Even if you don't remember the
discussion, you likely don't need to read other messages of this thread,
because it is self-contained.  And this is the whole point of this
style: to be able to read up on a (part of a) conversation later.  For
read-once contents, top posting can make perfect sense (although a chat
may be more suitable for such conversations).

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Partial function application

[Larry Garfield]

On Tue, May 11, 2021, at 1:32 PM, Nicolas Grekas wrote:

> > > BTW, ideally, partial functions should not increase the depth of the
> > > stacktrace at all. Do they?
> > >
> > > Nicolas
> >
> > They currently do, since they work by creating a Closure-esque object
> > called Partial with an __invoke() method.  However, if you partial the same
> > thing multiple times then only one stack level gets added.
> >
> 
> Nice. Would it be possible to optimize this and remove the extra frame? At
> least maybe for the (?) case?

I'd have to defer to Joe (he wrote the implementation), but I suspect not.  The 
partial has to be there to carry around the information of what callable to 
actually call and what the bound parameters are.  At that point, it's likely 
more work to decompose the Partial internally before calling it than to just 
call the Partial itself.

> This makes me wonder: can we create a partial programmatically? Wouldn't
> that be needed for some use cases?
> Partial::createFromCallable($callable, the-args)?
> 
> Nicolas

I cannot think of a use case where that would be needed.  Since you can 
partial-ize any callable, including a dynamic one, if you needed to do 
something like partial-ize one of a series of function calls you can do that 
already:

$c = match($some_input) {
  'A' => 'func_a',
  'B' => 'func_b',
  'C' => 'func_c',
};

$p = $c(1, 2 ?, 4);

Though at that point, just partialing them in the first place inside the match 
would be better as then you never have a function name in a string to begin 
with.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Discussion: Object-scoped RNG

[Levi Morrison via internals]

On Tue, May 11, 2021 at 6:58 AM Go Kudo  wrote:
>
> Hi internals.
>
> I previously proposed an object scope RNG implementation inside.
> However, the RFC was rejected after a vote.
>
> https://wiki.php.net/rfc/object_scope_prng
>
> Vote: https://externals.io/message/113888
> Discussion: https://externals.io/message/112819
>
> As per my previous proposal, PHP is currently in a very unclear state
> regarding the random number implementation.
>
> So I would like to ask a few questions.
>
> - Do you think that PHP needs an object-scoped random number
> implementation? And why?
> - If the API in the previous RFC was improved and voted on again, would you
> be willing to vote for it?
> - What issues do you think should have been resolved between proposal and
> ballot in the previous RFC?
>
> I would like a variety of opinions.
>
> Translated with www.DeepL.com/Translator (free version)
>
> Regards,
> Go Kudo

I would like to see an extension that doesn't contain the
backwards-compatibility breaking changes in the RFC. Every function,
type, and constant should be namespaced according to the extension.
For instance, if you want to call it `ext/rng`, then the namespace can
be `rng` or `Rng` or `RNG`.No exceptions for now! The previous
proposal had namespace things, and un-namespaced things, and breaking
changes, and I don't think that made a cohesive proposal.

Also, php-src generally doesn't suffix interfaces with the name
"Interface". Please provide another name for `RNGInterface`, like
`RandomNumberGenerator` or `RNG`.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Christian Schneider]

Am 11.05.2021 um 19:02 schrieb Calvin Buckley :
> - almost all modern mail clients are threaded, it's trivial to view
> context, so I want to see replies "above the fold"

Funnily enough the fact the mail clients are threaded nowadays is a good reason 
for me to use inline replies with rigorously trimmed down context: Someone who 
is actively following the thread will have minimal overhead to see what I'm 
referring to and people new to the thread can scroll to previous messages to 
get up-to-speed.

> - bottom posting goes against the grain of modern mail clients

First of all: I'm advocating inline quoting, not bottom posting.
I don't think this against the grain of modern clients. I have no problem going 
through my reply step by step, removing what is irrelevant to my reply and 
leave in what it relevant. At the same time it helps me to not forget something 
I wanted to answer. Yes, maybe mobile phones are a bit less well-equipped for 
this task but someone deciding to write detailed answers on a mobile phone 
should be willing to pay this price for the sake of the readers.

> I personally top-post (as it's the default for all the mail clients I
> use) when replying unless it's a point-by-point reply, in which case I
> reply inline.

I think you're pointing out exactly why a lot of long-time users of mailing 
lists prefer inline replies: Your personal (or even work) emails might often 
consist of nothing more than "I agree" or "Let's meet up", mailing lists are 
used for more in-depth discussions.

This means that the threshold for writing to the mailing list should be higher, 
i.e. a mail will probably contain multiple parts like an introduction, an 
explanation and a conclusion or question.
Therefore answers are often more complex too and reply to multiple points.

Another reason I sometimes hear at work is that you can forward a top-posting 
emails more easily to someone new to a thread. But this applies much less to a 
mailing list as people are normally subscribed to the list already and even if 
not there is an archive of all messages they can check for older messages if 
necessary.

Now while inline replies work for both point-by-point replies as well as short 
answers (you just strip down the original text to a minimum before adding your 
one-liner) the same is not true to top or bottom posting. They only work in 
simple cases unless you want to either copy/paste or (worse) paraphrase the 
original text within your answer. Both of these options are basically weaker 
versions of the inline quoting style (which as an additional bonus also support 
multiple levels of quoting).

Sure, some answers can be simple enough for top/bottom posting, but then again 
you have to ask yourself: Is this interesting enough for the 100s of people on 
this mailing list?
And if inline quoting works almost as well for simple answers, why not use it 
all the times so the reader does not have to switch reading modes?

- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Partial function application

[Nicolas Grekas]

> > > On Sun, Apr 25, 2021, at 2:25 PM, Larry Garfield wrote:
> > > > Greetings, Internalians!
> > > >
> > > > I would like to offer for your consideration another RFC,
> specifically
> > > > syntax for partial function application.
> > > >
> > > > https://wiki.php.net/rfc/partial_function_application
> > > >
> > > > It includes an implementation by Joe Watkins that is already about
> 95%
> > > > complete.  (There's some edge cases he's still sorting out, but all
> of
> > > > the typical cases should work already.)  Most of the design work
> comes
> > > > from Levi Morrison and Paul Crovella.  I helped out with the tests, a
> > > > few edge bits, and general instigator/nudge. :-)
> > > >
> > > > Discuss.
> > >
> > > It looks like the conversation has died down, and it's been two weeks,
> so
> > > pending any other notable feedback I'll open a vote on this RFC on
> Thursday
> > > or Friday.
> > >
> > > --Larry Garfield
> > >
> >
> > LGTM, thanks for the RFC!
> >
> > What about visibility? I suppose this works even outside the object
> scope?
> > should this be mentionned?
> > $foo = $this->somePrivateMethod(1, ?)
>
> We're pretty sure it will work, and if you return $foo to another caller
> and then call it, it will work fine.  We'll add a test to confirm that.
>
> > Would it make sense to support a way to use a placeholder for "all
> > remaining args"?
> > Eg:
> > $foo = some_func(1, ...?)
>
> That's already implicit in the way it works now.  If you placeholder at
> least one parameter, and then don't fill in all of the remaining
> parameters, any additional trailing parameters are always placeholdered.
> So $obj->foo(?) will always return a partial that has the same arity as
> foo() does, regardless of how many parameters it has.
>
> > Combined with my previous comment, this could replace
> > Closure::fromCallable() by a language construct, which is something that
> we
> > already discussed in another thread (we talked about some ::function
> > special suffix instead):
> > $foo = $this->somePrivateMethod(...?)
>
> Yep.  That's noted in the RFC.  Although not the primary intent, a nice
> side effect is that any_func(?) is now a safe way to turn any
> function/method into a callable to reference it.  That renders ::function
> or similar 98% unnecessary.  (The remaining cases are mostly where you need
> to collect data statically for compilation or similar.)
>

Great news!

> In this last form, we might make this result in Closure::fromCallable()
> > exactly. Aka no increase of the depth of the stack trace.
> >
> > BTW, ideally, partial functions should not increase the depth of the
> > stacktrace at all. Do they?
> >
> > Nicolas
>
> They currently do, since they work by creating a Closure-esque object
> called Partial with an __invoke() method.  However, if you partial the same
> thing multiple times then only one stack level gets added.
>

Nice. Would it be possible to optimize this and remove the extra frame? At
least maybe for the (?) case?

This makes me wonder: can we create a partial programmatically? Wouldn't
that be needed for some use cases?
Partial::createFromCallable($callable, the-args)?

Nicolas

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Alain D D Williams]

On Tue, May 11, 2021 at 05:34:41PM +0100, 😉 Good Guy 😉 wrote:
> With top posts people can go straight to the point raised by the poster.  If
> anyone is following the thread, he doesn't need 3 pages of previous posts. 
> All he needs is what is being posted by the poster in question.

I completely agree -- which is why when I reply I remove redundant stuff so
that only relevant lines from previous email are quoted to give context.

The way that I look at it is: 100+ people are going to be reading what I write.
If by spending 30 seconds trimming quotes so that it takes them 2 seconds to
understand what I am saying rather than 4 seconds then I have saved the list 2
seconds times 100+ each - ie 200+ seconds which costs me 30 seconds -- so an
overall win. **

BTW: a mutt user here - middle/bottom posting is easy.


** argue about the numbers if you wish, but that is the principle.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Partial function application

[Larry Garfield]

On Tue, May 11, 2021, at 11:57 AM, Nicolas Grekas wrote:
> > On Sun, Apr 25, 2021, at 2:25 PM, Larry Garfield wrote:
> > > Greetings, Internalians!
> > >
> > > I would like to offer for your consideration another RFC, specifically
> > > syntax for partial function application.
> > >
> > > https://wiki.php.net/rfc/partial_function_application
> > >
> > > It includes an implementation by Joe Watkins that is already about 95%
> > > complete.  (There's some edge cases he's still sorting out, but all of
> > > the typical cases should work already.)  Most of the design work comes
> > > from Levi Morrison and Paul Crovella.  I helped out with the tests, a
> > > few edge bits, and general instigator/nudge. :-)
> > >
> > > Discuss.
> >
> > It looks like the conversation has died down, and it's been two weeks, so
> > pending any other notable feedback I'll open a vote on this RFC on Thursday
> > or Friday.
> >
> > --Larry Garfield
> >
> 
> LGTM, thanks for the RFC!
> 
> What about visibility? I suppose this works even outside the object scope?
> should this be mentionned?
> $foo = $this->somePrivateMethod(1, ?)

We're pretty sure it will work, and if you return $foo to another caller and 
then call it, it will work fine.  We'll add a test to confirm that.

> Would it make sense to support a way to use a placeholder for "all
> remaining args"?
> Eg:
> $foo = some_func(1, ...?)

That's already implicit in the way it works now.  If you placeholder at least 
one parameter, and then don't fill in all of the remaining parameters, any 
additional trailing parameters are always placeholdered.  So $obj->foo(?) will 
always return a partial that has the same arity as foo() does, regardless of 
how many parameters it has.

> Combined with my previous comment, this could replace
> Closure::fromCallable() by a language construct, which is something that we
> already discussed in another thread (we talked about some ::function
> special suffix instead):
> $foo = $this->somePrivateMethod(...?)

Yep.  That's noted in the RFC.  Although not the primary intent, a nice side 
effect is that any_func(?) is now a safe way to turn any function/method into a 
callable to reference it.  That renders ::function or similar 98% unnecessary.  
(The remaining cases are mostly where you need to collect data statically for 
compilation or similar.)

> In this last form, we might make this result in Closure::fromCallable()
> exactly. Aka no increase of the depth of the stack trace.
> 
> BTW, ideally, partial functions should not increase the depth of the
> stacktrace at all. Do they?
> 
> Nicolas

They currently do, since they work by creating a Closure-esque object called 
Partial with an __invoke() method.  However, if you partial the same thing 
multiple times then only one stack level gets added.  That is:

function test($a, $b, $c, $d) { throw new Exception(); }

$first = test(?, ?, ?, ?);
$second = $first(1, ?);
$third = $second(2, ?);
$fourth = $third(3, ?);
$result = $fourth(4);

The stack at the end will contain only one partial "level", not 4.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Calvin Buckley]

I'm just going to say...

- almost all modern mail clients are threaded, it's trivial to view
context, so I want to see replies "above the fold"
- bottom posting goes against the grain of modern mail clients
- overall, it just feels like arbitrary preferences set decades ago;
worst case it feels like hazing against people who don't use mutt/pine

I personally top-post (as it's the default for all the mail clients I
use) when replying unless it's a point-by-point reply, in which case I
reply inline. I'm not bothered by bottom posting nor do I make a fuss
when I see other conventions, but it's more inconvenient to read.

(I also have to set my client to plain text manually per message -
that's another can of worms...)

On Mon, 2021-05-10 at 22:51 +0100, Kamil Tekiela wrote:
> Hi Internals,
> 
> Could we drop the bottom-posting rule?
> 
> Almost all new contributors fall into this trap and reply to a thread
> by
> top-posting, only to get chastised by someone else on the list. It's
> really
> difficult to remember to delete the default reply. Mail clients don't
> make
> it easy for us; it's hidden by default. Bottom-posting makes reading
> the
> thread much more difficult too. The actual reply gets lost in between
> the
> quoted content. I often get confused about what is new and what was
> quoted. Many modern clients are designed to handle top-posting and
> don't
> handle bottom-posting well. People are usually used to it and they
> read
> from top to bottom. I don't know if in the past some mail clients
> defaulted
> to bottom-posting but right now it just seems like an unnecessary
> annoyance.
> 
> If you want to quote someone then it makes sense to copy a part of
> the
> message and then add a reply below, but forcing people to remove the
> default reply from the mail client and then add the whole previous
> message
> on top of your own reply isn't very productive. It wastes time and
> screen
> space.
> 
> Could we please change this rule or at least stop enforcing it?
> Do people actually have mail clients that don't automatically hide
> the
> previous conversation? If not, then I think we can let people top-
> post.
> 
> Regards,
> Kamil

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Nikita Popov]

On Tue, May 11, 2021 at 6:56 PM Matt Fonda  wrote:

> On Tue, May 11, 2021 at 7:45 AM Nikita Popov  wrote:
>
>> My thought here is that a constructor with (only) promoted properties is
>> hardly a constructor at all -- it's more like a special syntax for
>> declaring properties that happens to re-use the constructor notation,
>> because that allows it generalize in certain ways. It could have been
>> implemented with some other syntax that didn't explicitly mention
>> constructors at all, such as class Point($x, $y, $z) {} or something.
>>
>
> Agreed. I've personally been a little hesitant to start using CPP because
> of this. Declare constructor parameters AND declare properties AND
> magically provide a constructor implementation that sets their values. It
> looks like a constructor, but it's actually a little different. For me,
> this proposal would really help clear that up.
>
> When I see a method with an empty body, I think "this method does have an
> implementation, and that implementation does exactly nothing." In the case
> of CPP, this isn't true. The method appears to do exactly nothing, but in
> fact it has an automatically defined implementation that sets the
> properties to the given values.
>
> When I see a semi-colon-terminated method, I think "this method has no
> implementation *here*; one will be provided from somewhere else." This is
> the case in abstract classes and interfaces--the subclass provides the
> implementation. And it's the case in CPP too--an implementation that sets
> the properties to the given values is automatically provided. For this
> reason, I don't see it as inconsistent. The semi-colon means someone else
> will provide an implementation, and CPP does just that.
>

After you put it into these terms, this reminds me a lot of
https://wiki.php.net/rfc/property_accessors#implicit_implementation. For
accessors there's very much a difference between

public $prop { get; } // auto-generated get

and

public $prop { get {} } // explicit get that doesn't do anything

Making "allow replacing {} with ;" as a general feature would certainly
pose a problem for this choice of syntax (which is inspired by C#).

Regards,
Nikita

Re: [PHP-DEV] [RFC] Partial function application

[David Gebler]

On Tue, May 11, 2021 at 4:39 PM Larry Garfield 
wrote:

> It looks like the conversation has died down, and it's been two weeks, so
> pending any other notable feedback I'll open a vote on this RFC on Thursday
> or Friday.
>
> --Larry Garfield
>
>
>
 My only query / point of consideration is a very minor one for what is
otherwise an enthusiastic (non-voting) +1. In relation to one of the
examples:

function whole($one, $two) { /* ... */ }
// equivalent to calling whole(1, 2, 3)
$result = whole(?, 2)(1, 3);

Is there a risk this has the potential to be confusing? We've always had
this quirk in PHP of being able to pass extra unspecified parameters in
function calls, but with the exception of variadic functions the
expectation is that they are ignored. Arguably if I saw this:

function whole($one, $two) { /* ... */ }
$partial = whole(?, 2);
$result = partial(1, 3);

I might expect it to semantically translate to:

function partial($one) { return whole($one, 2); }

with the extra parameter, 3, ignored as per convention for any other
function receiving undefined extra params. But the RFC says this parameter
would be passed to whole(). Which is not unreasonable, but yeah I guess it
strikes me it's kind of a quirk in itself to do it that way.

-Dave

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Kamil Tekiela]

> I doubt "bottom posting" is a term people who started online in the last
10
years know - with today/yesterday's example, my takeaway was the original
poster didn't know what it meant.

Yeah, the first time I heard about it is on this mailing list. I didn't
know it was a thing before, and I admit I might still not understand why it
is a thing. All my life I have been used to "newest first". Whenever I
encountered a website or an email that asked me to scroll for the newer
content it upset me. Now I see that some developers prefer this style. It
could also be the fault of user agents that don't scroll/hide the old
content and force me to read it again.

Re: [PHP-DEV] [RFC] Partial function application

[Nicolas Grekas]

> On Sun, Apr 25, 2021, at 2:25 PM, Larry Garfield wrote:
> > Greetings, Internalians!
> >
> > I would like to offer for your consideration another RFC, specifically
> > syntax for partial function application.
> >
> > https://wiki.php.net/rfc/partial_function_application
> >
> > It includes an implementation by Joe Watkins that is already about 95%
> > complete.  (There's some edge cases he's still sorting out, but all of
> > the typical cases should work already.)  Most of the design work comes
> > from Levi Morrison and Paul Crovella.  I helped out with the tests, a
> > few edge bits, and general instigator/nudge. :-)
> >
> > Discuss.
>
> It looks like the conversation has died down, and it's been two weeks, so
> pending any other notable feedback I'll open a vote on this RFC on Thursday
> or Friday.
>
> --Larry Garfield
>

LGTM, thanks for the RFC!

What about visibility? I suppose this works even outside the object scope?
should this be mentionned?
$foo = $this->somePrivateMethod(1, ?)

Would it make sense to support a way to use a placeholder for "all
remaining args"?
Eg:
$foo = some_func(1, ...?)

Combined with my previous comment, this could replace
Closure::fromCallable() by a language construct, which is something that we
already discussed in another thread (we talked about some ::function
special suffix instead):
$foo = $this->somePrivateMethod(...?)

In this last form, we might make this result in Closure::fromCallable()
exactly. Aka no increase of the depth of the stack trace.

BTW, ideally, partial functions should not increase the depth of the
stacktrace at all. Do they?

Nicolas

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Matt Fonda]

On Tue, May 11, 2021 at 7:45 AM Nikita Popov  wrote:

> My thought here is that a constructor with (only) promoted properties is
> hardly a constructor at all -- it's more like a special syntax for
> declaring properties that happens to re-use the constructor notation,
> because that allows it generalize in certain ways. It could have been
> implemented with some other syntax that didn't explicitly mention
> constructors at all, such as class Point($x, $y, $z) {} or something.
>

Agreed. I've personally been a little hesitant to start using CPP because
of this. Declare constructor parameters AND declare properties AND
magically provide a constructor implementation that sets their values. It
looks like a constructor, but it's actually a little different. For me,
this proposal would really help clear that up.

When I see a method with an empty body, I think "this method does have an
implementation, and that implementation does exactly nothing." In the case
of CPP, this isn't true. The method appears to do exactly nothing, but in
fact it has an automatically defined implementation that sets the
properties to the given values.

When I see a semi-colon-terminated method, I think "this method has no
implementation *here*; one will be provided from somewhere else." This is
the case in abstract classes and interfaces--the subclass provides the
implementation. And it's the case in CPP too--an implementation that sets
the properties to the given values is automatically provided. For this
reason, I don't see it as inconsistent. The semi-colon means someone else
will provide an implementation, and CPP does just that.

Regards,
--Matthew

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Christian Schneider]

Am 11.05.2021 um 18:42 schrieb Kamil Tekiela :
> Compare the two messages from Sara, the first where she top posted and the
> second where she bottom posted. Which one is more clear?
> https://imgur.com/TUiHval

The second one which shows me what Sara is referring to.
Imagine it just said "I don't know what Mel is talking about" without you 
seeing what Mel said right away.

> I completely agree with Good Guy. Top posting is just way more convenient.


I disagree.
What some people call inter-posting as way more convenient because it has the 
context of what you are referring to right next to your answer.

And yes: People *should* trim down the context. It also forces you to go 
through the email and remove what is irrelevant. Every second you spend making 
your message clearer and quicker to digest will save many seconds on the 
reading end.

- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Peter Bowyer]

On Mon, 10 May 2021 at 22:52, Kamil Tekiela  wrote:

> Almost all new contributors fall into this trap and reply to a thread by
> top-posting, only to get chastised by someone else on the list.
>

I like bottom-posting or point-by-point replies, but would drop the rule
and make the list a more welcoming place for newcomers.

I doubt "bottom posting" is a term people who started online in the last 10
years know - with today/yesterday's example, my takeaway was the original
poster didn't know what it meant. There's also English familiarity to
account for.

Peter

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[😉 Good Guy 😉]

On 11/05/2021 15:36, Sara Golemon wrote:

On Tue, May 11, 2021 at 9:21 AM Chase Peeler  wrote:

On Tue, May 11, 2021 at 2:34 AM Mel Dafert  wrote:

(Gmail certainly can't, it can't even send non-HTML mails, and even with
K-9 I have to remember doing it.)


I’m sending this from gmail on my phone, so not sure what you are talking
about.


This plaintext reply sent via Gmail web client. I don't know what Mel is
talking about either.



I decided to bottom-post and in HTML to see if it works here.  I know it 
is going to cause unnecessary discussion about HTML on these 
forums/newsgroups or whatever they are called these days.








--

With over 1.3 billion devices now running Windows 10, customer 
satisfaction is higher than any previous version of windows.

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Marco Pivetta]

And readable

On Tue, May 11, 2021, 18:42 Kamil Tekiela  wrote:

> I completely agree with Good Guy. Top posting is just way more convenient.
>

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Kamil Tekiela]

Compare the two messages from Sara, the first where she top posted and the
second where she bottom posted. Which one is more clear?
https://imgur.com/TUiHval

I completely agree with Good Guy. Top posting is just way more convenient.

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[😉 Good Guy 😉]

People are using smart phones these days so top posting is very 
convenient.  As you say people don't read the entire thread so why keep 
them in the posts when replying?  Surely, there are other means to get 
the gist of the discussion if one wants to be reminded about.



On 11/05/2021 08:23, Pierre wrote:
I'm opposed to dropping the bottom-posting rule, for the simple reason 
that you naturally read from top to bottom, and most people don't 
bother reading again the whole thread when they read a single answer.






--

With over 1.3 billion devices now running Windows 10, customer 
satisfaction is higher than any previous version of windows.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[😉 Good Guy 😉]

With top posts people can go straight to the point raised by the 
poster.  If anyone is following the thread, he doesn't need 3 pages of 
previous posts.  All he needs is what is being posted by the poster in 
question.


People don't need the history of entire thread in one post because it is 
available by some other means.


On 11/05/2021 08:11, Marco Pivetta wrote:


Heck, even my phone can read top-posts,




--

With over 1.3 billion devices now running Windows 10, customer 
satisfaction is higher than any previous version of windows.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Chase Peeler]

On Tue, May 11, 2021 at 11:48 AM Michael Morris  wrote:

> If this list has ever had a "bike shed" issue, this would be it.
>
> https://en.wikipedia.org/wiki/Law_of_triviality
>
>
>
I agree, but it's within its own thread and not hijacking other ones, so no
harm in discussing it.


>
> On Tue, May 11, 2021 at 10:01 AM Mel Dafert  wrote:
>
> > >> This plaintext reply sent via Gmail web client. I don't know what Mel
> is
> > >> talking about either.
> > >>
> > >>
> > >Gmail's web client is what I normally use, and have never had an issue
> > with
> > >it.
> >
> > Sorry for being unclear - I meant the Gmail android app.
> >
> > If the app does have an option for plaintext emails, I am not able to
> find
> > it.
> > If it does, that might also be useful to document somewhere, so people
> > like me can actually use it :)
> >
> > Even then, I also don't think it offers an option to bottom-post by
> > default - which K-9 and Thunderbird do.
> > (No idea about the Gmail web client - I don't use it regularly.)
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
>


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Michael Morris]

If this list has ever had a "bike shed" issue, this would be it.

https://en.wikipedia.org/wiki/Law_of_triviality



On Tue, May 11, 2021 at 10:01 AM Mel Dafert  wrote:

> >> This plaintext reply sent via Gmail web client. I don't know what Mel is
> >> talking about either.
> >>
> >>
> >Gmail's web client is what I normally use, and have never had an issue
> with
> >it.
>
> Sorry for being unclear - I meant the Gmail android app.
>
> If the app does have an option for plaintext emails, I am not able to find
> it.
> If it does, that might also be useful to document somewhere, so people
> like me can actually use it :)
>
> Even then, I also don't think it offers an option to bottom-post by
> default - which K-9 and Thunderbird do.
> (No idea about the Gmail web client - I don't use it regularly.)
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Partial function application

[Larry Garfield]

On Sun, Apr 25, 2021, at 2:25 PM, Larry Garfield wrote:
> Greetings, Internalians!
> 
> I would like to offer for your consideration another RFC, specifically 
> syntax for partial function application.
> 
> https://wiki.php.net/rfc/partial_function_application
> 
> It includes an implementation by Joe Watkins that is already about 95% 
> complete.  (There's some edge cases he's still sorting out, but all of 
> the typical cases should work already.)  Most of the design work comes 
> from Levi Morrison and Paul Crovella.  I helped out with the tests, a 
> few edge bits, and general instigator/nudge. :-)
> 
> Discuss.

It looks like the conversation has died down, and it's been two weeks, so 
pending any other notable feedback I'll open a vote on this RFC on Thursday or 
Friday.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Guilliam Xavier]

On Tue, May 11, 2021 at 5:07 PM Pierre  wrote:

> Le 10/05/2021 à 18:58, Larry Garfield a écrit :
>
> > I agree that in the grand scheme of things this would be a minor matter,
> but aesthetically I would prefer it as well.  The {} annoys me, CS tools or
> no.
> >
> > Related: I feel the same way about empty-classes and interfaces, which
> is often the case for exceptions where all you're doing is declaring a
> type.  I figure that would get even more pushback, though. :-)
> >
> > As a data point, you can already do the same "semi-colon for no body"
> for foreach, for, and while loops.  I've only ever done it on foreach to
> runout an iterator, but it works on all three today.
> >
> > --Larry Garfield
>
> I didn't saw this answer at first, but I agree that:
>
> ```
>
> interface MyLibraryException;
>
>
> class DefaultMyLibraryException extends \RuntimeException implements
> MyLibraryException;
>
> ```
>
> Is an excellent use case for this!
>
>
I'm probably biased by my C++ background but to me this looks like "forward
declarations" (i.e. just declares types but doesn't *define* them) :/

Regards,

-- 
Guilliam Xavier

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Christian Schneider]

Am 11.05.2021 um 17:01 schrieb Mel Dafert :
>>> This plaintext reply sent via Gmail web client. I don't know what Mel is
>>> talking about either.
>>> 
>> Gmail's web client is what I normally use, and have never had an issue with
>> it.
> 
> Sorry for being unclear - I meant the Gmail android app.
> 
> If the app does have an option for plaintext emails, I am not able to find it.

As long as the Android Gmail App includes a text/plain version alongside the 
html one, everything is fine.

And as far as I can see (doing a quick and not too comprehensive test with a 
friend who has the app installed) it does, so no need to configure anything.

- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Claude Pache]

> Le 11 mai 2021 à 09:11, Marco Pivetta  a écrit :
> 
> Sure, why not: email clients are decent enough to hide quoted sections
> anyway 👍
> 
> Heck, even my phone can read top-posts, and the rest of the folks (reddit,
> mostly) use https://externals.io/ anyway 🤷
> 
> Feel free to call me out for top-posting this 😛

Then, after a first top-post, someone comes and middle-post, and you have to 
guess whether they’re bottom-answering the top part or top-answering the bottom 
part. Or both.

Sure, email clients are decent enough to “hide quoted sections” (which I read: 
“hide the mess”), but not to sort them.

—Claude

> 
> On Mon, May 10, 2021, 23:52 Kamil Tekiela  wrote:
> 
>> Hi Internals,
>> 
>> Could we drop the bottom-posting rule?
>> 
>> Almost all new contributors fall into this trap and reply to a thread by
>> top-posting, only to get chastised by someone else on the list. It's really
>> difficult to remember to delete the default reply. Mail clients don't make
>> it easy for us; it's hidden by default. Bottom-posting makes reading the
>> thread much more difficult too. The actual reply gets lost in between the
>> quoted content. I often get confused about what is new and what was
>> quoted. Many modern clients are designed to handle top-posting and don't
>> handle bottom-posting well. People are usually used to it and they read
>> from top to bottom. I don't know if in the past some mail clients defaulted
>> to bottom-posting but right now it just seems like an unnecessary
>> annoyance.
>> 
>> If you want to quote someone then it makes sense to copy a part of the
>> message and then add a reply below, but forcing people to remove the
>> default reply from the mail client and then add the whole previous message
>> on top of your own reply isn't very productive. It wastes time and screen
>> space.
>> 
>> Could we please change this rule or at least stop enforcing it?
>> Do people actually have mail clients that don't automatically hide the
>> previous conversation? If not, then I think we can let people top-post.
>> 
>> Regards,
>> Kamil
>> 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Pierre]

Le 10/05/2021 à 18:58, Larry Garfield a écrit :


I agree that in the grand scheme of things this would be a minor matter, but 
aesthetically I would prefer it as well.  The {} annoys me, CS tools or no.

Related: I feel the same way about empty-classes and interfaces, which is often 
the case for exceptions where all you're doing is declaring a type.  I figure 
that would get even more pushback, though. :-)

As a data point, you can already do the same "semi-colon for no body" for 
foreach, for, and while loops.  I've only ever done it on foreach to runout an iterator, 
but it works on all three today.

--Larry Garfield


I didn't saw this answer at first, but I agree that:

```

interface MyLibraryException;


class DefaultMyLibraryException extends \RuntimeException implements 
MyLibraryException;


```

Is an excellent use case for this!

Regards,

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Mel Dafert]

>> This plaintext reply sent via Gmail web client. I don't know what Mel is
>> talking about either.
>>
>>
>Gmail's web client is what I normally use, and have never had an issue with
>it.

Sorry for being unclear - I meant the Gmail android app.

If the app does have an option for plaintext emails, I am not able to find it.
If it does, that might also be useful to document somewhere, so people like me 
can actually use it :)

Even then, I also don't think it offers an option to bottom-post by default - 
which K-9 and Thunderbird do.
(No idea about the Gmail web client - I don't use it regularly.)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Pierre]

Le 11/05/2021 à 16:50, Chase Peeler a écrit :

On Tue, May 11, 2021 at 10:48 AM Matīss Treinis  wrote:


Hi Sara,

  > While it's certainly silly/pointless to have a nil constructor when
there are non-promoted args present, I think that deliberately making
that mode special (read: inconsistent) is the wrong way to go.

Sorry, but I don't follow - so you would prefer that this:

 public function __construct();

be valid syntax as well, considering within the scope of the proposed?
Am I reading this right?



Yes. It might be silly and pointless, but, it doesn't have any negative
side effects, so why not?


I agree, even for all methods, if I can avoid the {} when I don't need it.

To go further, for any method that return void or a nullable type, it 
would be a nice to have the semicolon syntax automatically returning 
null or void when possible, for when implementing an interface method or 
abstract method you actually don't need to implement.


Regards,

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Chase Peeler]

On Tue, May 11, 2021 at 10:48 AM Matīss Treinis  wrote:

> Hi Sara,
>
>  > While it's certainly silly/pointless to have a nil constructor when
> there are non-promoted args present, I think that deliberately making
> that mode special (read: inconsistent) is the wrong way to go.
>
> Sorry, but I don't follow - so you would prefer that this:
>
> public function __construct();
>
> be valid syntax as well, considering within the scope of the proposed?
> Am I reading this right?
>
>
Yes. It might be silly and pointless, but, it doesn't have any negative
side effects, so why not?


> - Matīss
>
> On Tue, May 11, 2021 at 09:33, Sara Golemon  wrote:
> > On Tue, May 11, 2021 at 5:18 AM Matīss Treinis  > > wrote:
> > > Yes, just to clarify the scope of my initial proposal, this should
> > only
> > > ever apply to promoted constructors that have 1 or more promoted
> > > parameters, and no not-promoted parameters.
> > >
> >
> > Hard disagree. While it's certainly silly/pointless to have a nil
> > constructor when there are non-promoted args present, I think that
> > deliberately making that mode special (read: inconsistent) is the
> > wrong way to go.
> >
> > > These would NOT be considered valid:
> > > public function __construct();
> > >
> >
> > For example, Niki's reply showed a place where that mode is perfectly
> > reasonable (singleton finals).  If you must have this syntactic
> > sugar, then please make it consistent.
> >
> > > as well as anything not related to __construct.
> > >
> >
> > I'd be willing to go along with inconsistency since once you allow
> > syntax you can't unallow it without pain. So while I don't love the
> > tack, I'll follow it if we do this feature. (which IMO we shouldn't).
> >
> >
> >
> > On Tue, May 11, 2021 at 8:59 AM Matīss Treinis  > > wrote:
> > > If there are no super strong arguments on why this should not
> > happen or go
> > > to RFC, I will draft a RFC and from there, the usual process
> > applies.
> > >
> >
> > I think you've heard a number of strong arguments why it should not
> > happen, but I also think this deserves its chance to be fleshed out
> > and voted on, so by all means, do work the RFC.
> >
> > -Sara
>
>

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Matīss Treinis]

Hi Sara,

> While it's certainly silly/pointless to have a nil constructor when 
there are non-promoted args present, I think that deliberately making 
that mode special (read: inconsistent) is the wrong way to go.


Sorry, but I don't follow - so you would prefer that this:

   public function __construct();

be valid syntax as well, considering within the scope of the proposed? 
Am I reading this right?


- Matīss

On Tue, May 11, 2021 at 09:33, Sara Golemon  wrote:
On Tue, May 11, 2021 at 5:18 AM Matīss Treinis > wrote:
> Yes, just to clarify the scope of my initial proposal, this should 
only

> ever apply to promoted constructors that have 1 or more promoted
> parameters, and no not-promoted parameters.
>

Hard disagree. While it's certainly silly/pointless to have a nil 
constructor when there are non-promoted args present, I think that 
deliberately making that mode special (read: inconsistent) is the 
wrong way to go.


> These would NOT be considered valid:
> public function __construct();
>

For example, Niki's reply showed a place where that mode is perfectly 
reasonable (singleton finals).  If you must have this syntactic 
sugar, then please make it consistent.


> as well as anything not related to __construct.
>

I'd be willing to go along with inconsistency since once you allow 
syntax you can't unallow it without pain. So while I don't love the 
tack, I'll follow it if we do this feature. (which IMO we shouldn't).




On Tue, May 11, 2021 at 8:59 AM Matīss Treinis > wrote:
> If there are no super strong arguments on why this should not 
happen or go
> to RFC, I will draft a RFC and from there, the usual process 
applies.

>

I think you've heard a number of strong arguments why it should not 
happen, but I also think this deserves its chance to be fleshed out 
and voted on, so by all means, do work the RFC.


-Sara

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Pierre]

Le 11/05/2021 à 16:39, Chase Peeler a écrit :

I agree. I think making things inconsistent between constructors and other
methods is something that can be lived with - there are already other
things special about constructors that don't apply to other methods - but
we should at least allow consistency among constructors and allow the
trailing semicolon in all cases.


As Sara stated, the example of the singleton final constructor is a good 
one, but another one I could think about which applies to *all methods* 
is when implementing an interface, you may want to keep some of the 
implemented methods just empty.


Why not applying the semicolon syntax as well for all methods ? It 
doesn't seem like bad idea to me, I often write empty methods when 
implementing the null object pattern, or when I have partial 
implementations for specific use case, or just when I don't need to 
implement an abstract or interface method.


I'm all in for consistency between constructor and all methods and allow 
the semicolon to replace any empty method body.


Regards,

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Nikita Popov]

On Tue, May 11, 2021 at 4:37 PM Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:

> Le Tue, 11 May 2021 10:58:57 +0200,
> Nikita Popov  a écrit :
>
> > If we allow it, I would restrict it to specifically the case of a) a
> > promoted constructor b) which has *only* promoted parameters. I don't
> think
> > we should allow replacing "{}" with ";" for methods in the general case.
>
> This would create a subtle difference of allowed syntax between a
> constructor
>  and an other method, and between a constructor with promoted parameters
> and
>  without. I think we should avoid this.
>
> I even thought we merged changes to make constructors more like the other
>  methods, but I just checked and it seems the RFCs to allow ": void" on
>  constructors were declined.
>

My thought here is that a constructor with (only) promoted properties is
hardly a constructor at all -- it's more like a special syntax for
declaring properties that happens to re-use the constructor notation,
because that allows it generalize in certain ways. It could have been
implemented with some other syntax that didn't explicitly mention
constructors at all, such as class Point($x, $y, $z) {} or something.

I don't think there's any particularly good reason to have a body-less
constructor outside the promotion case. The example given by Bruce

private final function __construct();

is going to throw a warning since PHP 8 -- while I lobbied against that
decision at the time, final private methods no longer have an effect, and
declaring such a constructor will buy you nothing apart from that warning.

If a body-less non-promoted constructor is used, the most likely assumption
would be that the programmer forgot an "abstract" modifier.

Is there some use-case for empty constructors that I'm missing here?

Regards,
Nikita

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Chase Peeler]

On Tue, May 11, 2021 at 10:36 AM Sara Golemon  wrote:

> On Tue, May 11, 2021 at 9:21 AM Chase Peeler 
> wrote:
> > On Tue, May 11, 2021 at 2:34 AM Mel Dafert  wrote:
> > > (Gmail certainly can't, it can't even send non-HTML mails, and even
> with
> > > K-9 I have to remember doing it.)
> > >
> > I’m sending this from gmail on my phone, so not sure what you are talking
> > about.
> >
>
> This plaintext reply sent via Gmail web client. I don't know what Mel is
> talking about either.
>
>
Gmail's web client is what I normally use, and have never had an issue with
it.

For work I use outlook and I often do in-line replies as well. That's
usually combined with a top post reply saying "see inline" since top
posting is the convention everyone uses at work. I can also tell you it's
much more difficult to go back through a long thread of emails when you
have to read everything from the bottom up.

I also wanted to address a few comments people have made around being told
to top post. I've seen my fair share of snark on this board. Not once have
I ever seen anyone make a big deal out of someone top posting. I don't even
recall a time when someone replied JUST to tell them not to top post. I've
only seen it presented as a gentle reminder as part of a reply on the
actual topic.


> -Sara
>



-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] New in initializers

[Larry Garfield]

On Tue, May 11, 2021, at 8:57 AM, Rowan Tommins wrote:
> On 11/05/2021 14:12, Dik Takken wrote:
> > So the use of "new" in initializers would require extending this base
> > class and call the parent constructor. Maybe forgetting to do so could
> > throw, preventing initializers from silently not working.
> 
> 
> If we managed to get that working, I wonder if we could also include a 
> check for uninitialized typed properties, a bit like Swift's "two-phase 
> initializers". In short, make this throw an error:
> 
> class Foo extends \PHP\Base {
>      private Logger $logger;
> 
>      public function __construct() {
>      parent::construct(); // "Error: Property $logger has no default 
> and was not initialized before calling Base constructor"
>      }
> }
> 
> This would catch bugs closer to their source, where currently there is 
> no error until $logger is accessed.
> 
> 
> However, the "if" at the beginning of this message is quite a big one: 
> it's not obvious where to assert any of this, because the constructor is 
> just called as a normal method *after* the engine considers the object 
> to be "created".

In practice, I almost always see the parent constructor called first, then the 
child constructor does its own thing.  Having the language require you to do it 
backwards in order to use a new feature would be... well, not technically a BC 
break per se, but certainly invalidating what is currently standard practice.

If I'm following correctly, the concern is cases like this:

class Point {
  private Logger $logger = new FancyLogger();
  public function __construct(public int $x, public int $y) {
$this->logger->log("Point made.");
  }
}

class FancyLogger {
public function __construct() {
  $this->db = new DatabaseConnection();
  $this->db->write('Logger start.');
}
}

$p1 = new Point(); // This writes "Logger start" then "Point made."

$p2 = unserialize(serialize($p1)); // This writes just "Logger start."

Am I understanding that right?  If so, I'm... unclear why that is any more of 
an issue than doing it the manual way now.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Chase Peeler]

On Tue, May 11, 2021 at 10:34 AM Sara Golemon  wrote:

> On Tue, May 11, 2021 at 5:18 AM Matīss Treinis 
> wrote:
> > Yes, just to clarify the scope of my initial proposal, this should only
> > ever apply to promoted constructors that have 1 or more promoted
> > parameters, and no not-promoted parameters.
> >
>
> Hard disagree. While it's certainly silly/pointless to have a nil
> constructor when there are non-promoted args present, I think that
> deliberately making that mode special (read: inconsistent) is the wrong way
> to go.
>
> > These would NOT be considered valid:
> > public function __construct();
> >
>
> For example, Niki's reply showed a place where that mode is perfectly
> reasonable (singleton finals).  If you must have this syntactic sugar, then
> please make it consistent.
>
> > as well as anything not related to __construct.
> >
>
> I'd be willing to go along with inconsistency since once you allow syntax
> you can't unallow it without pain. So while I don't love the tack, I'll
> follow it if we do this feature. (which IMO we shouldn't).
>
>
>
I agree. I think making things inconsistent between constructors and other
methods is something that can be lived with - there are already other
things special about constructors that don't apply to other methods - but
we should at least allow consistency among constructors and allow the
trailing semicolon in all cases.


>
> On Tue, May 11, 2021 at 8:59 AM Matīss Treinis 
> wrote:
> > If there are no super strong arguments on why this should not happen or
> go
> > to RFC, I will draft a RFC and from there, the usual process applies.
> >
>
> I think you've heard a number of strong arguments why it should not happen,
> but I also think this deserves its chance to be fleshed out and voted on,
> so by all means, do work the RFC.
>
> -Sara
>


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Côme Chilliet]

Le Tue, 11 May 2021 10:58:57 +0200,
Nikita Popov  a écrit :

> If we allow it, I would restrict it to specifically the case of a) a
> promoted constructor b) which has *only* promoted parameters. I don't think
> we should allow replacing "{}" with ";" for methods in the general case.

This would create a subtle difference of allowed syntax between a constructor
 and an other method, and between a constructor with promoted parameters and
 without. I think we should avoid this.

I even thought we merged changes to make constructors more like the other
 methods, but I just checked and it seems the RFCs to allow ": void" on
 constructors were declined.

Côme

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Sara Golemon]

On Tue, May 11, 2021 at 9:21 AM Chase Peeler  wrote:
> On Tue, May 11, 2021 at 2:34 AM Mel Dafert  wrote:
> > (Gmail certainly can't, it can't even send non-HTML mails, and even with
> > K-9 I have to remember doing it.)
> >
> I’m sending this from gmail on my phone, so not sure what you are talking
> about.
>

This plaintext reply sent via Gmail web client. I don't know what Mel is
talking about either.

-Sara

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Sara Golemon]

On Tue, May 11, 2021 at 5:18 AM Matīss Treinis  wrote:
> Yes, just to clarify the scope of my initial proposal, this should only
> ever apply to promoted constructors that have 1 or more promoted
> parameters, and no not-promoted parameters.
>

Hard disagree. While it's certainly silly/pointless to have a nil
constructor when there are non-promoted args present, I think that
deliberately making that mode special (read: inconsistent) is the wrong way
to go.

> These would NOT be considered valid:
> public function __construct();
>

For example, Niki's reply showed a place where that mode is perfectly
reasonable (singleton finals).  If you must have this syntactic sugar, then
please make it consistent.

> as well as anything not related to __construct.
>

I'd be willing to go along with inconsistency since once you allow syntax
you can't unallow it without pain. So while I don't love the tack, I'll
follow it if we do this feature. (which IMO we shouldn't).



On Tue, May 11, 2021 at 8:59 AM Matīss Treinis  wrote:
> If there are no super strong arguments on why this should not happen or go
> to RFC, I will draft a RFC and from there, the usual process applies.
>

I think you've heard a number of strong arguments why it should not happen,
but I also think this deserves its chance to be fleshed out and voted on,
so by all means, do work the RFC.

-Sara

Re: [PHP-DEV] [RFC] Deprecate ticks

[Sara Golemon]

On Tue, May 11, 2021 at 3:53 AM Nikita Popov  wrote:

> I'd like to propose the depreciation of the ticks mechanism:
> https://wiki.php.net/rfc/deprecate_ticks
>
> I'm submitting this separately from the PHP 8.1 deprecations RFC, as this
> is a language change, even if not a particularly important one...
>
>
I came here to plea for the poor, disrespected ticks function.
Then I went to github and asked who was using it...
In the 10,000 results which came up for that string in actual PHP code, I
paged through the first 20% (2000) cases.
They were ALL either a phpt test file, or an auto-generated proxy function
(which appears to not actually have any uses).

So yeah.  Pour one out for ol' ticks.  May it rest in peace (following a
suitable deprecation period leading up to PHP 9.0).

-Sara

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Chase Peeler]

On Tue, May 11, 2021 at 2:34 AM Mel Dafert  wrote:

> On 10 May 2021 23:57:51 CEST, Christian Schneider 
> wrote:
> >No.
> >Outlook is not modern.
>
> While I agree with this (and I also agree with keeping bottom-posting), I
> feel like we could make this easier
> for new contributors by giving some examples of which clients to use and
> how to configure them.
> What clients are people using that make this convenient?
> On desktop, I assume Thunderbird can do this, and my web client (zimbra)
> also can.
> On mobile, I've settled with the beta version of K-9 - I don't know of any
> other client that can do this.
> (Gmail certainly can't, it can't even send non-HTML mails, and even with
> K-9 I have to remember doing it.)


I’m sending this from gmail on my phone, so not sure what you are talking
about.


> And please don't say that mobile clients don't matter - if we want to make
> it easy for new people to join,
> we should also make sure we support using mobile.
>
> Regards,
> Mel
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
> --
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Sara Golemon]

-1. Top posting encourages lazy email composition. One should put an ounce
of thought into how one organizes a response.

On Mon, May 10, 2021 at 4:52 PM Kamil Tekiela  wrote:
>
> Hi Internals,
>
> Could we drop the bottom-posting rule?
>
> Almost all new contributors fall into this trap and reply to a thread by
> top-posting, only to get chastised by someone else on the list. It's
really
> difficult to remember to delete the default reply. Mail clients don't make
> it easy for us; it's hidden by default. Bottom-posting makes reading the
> thread much more difficult too. The actual reply gets lost in between the
> quoted content. I often get confused about what is new and what was
> quoted. Many modern clients are designed to handle top-posting and don't
> handle bottom-posting well. People are usually used to it and they read
> from top to bottom. I don't know if in the past some mail clients
defaulted
> to bottom-posting but right now it just seems like an unnecessary
> annoyance.
>
> If you want to quote someone then it makes sense to copy a part of the
> message and then add a reply below, but forcing people to remove the
> default reply from the mail client and then add the whole previous message
> on top of your own reply isn't very productive. It wastes time and screen
> space.
>
> Could we please change this rule or at least stop enforcing it?
> Do people actually have mail clients that don't automatically hide the
> previous conversation? If not, then I think we can let people top-post.
>
> Regards,
> Kamil

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Matīss Treinis]

Oh absolutely, and many thanks for doing the code part, Nikita!

I would propose leaving this open for debate till, say, 15th of May here on
internals ML to gather more input.

If there are no super strong arguments on why this should not happen or go
to RFC, I will draft a RFC and from there, the usual process applies.

- Matīss


On Tue, May 11, 2021 at 12:41 PM Nikita Popov  wrote:

> On Tue, May 11, 2021 at 12:17 PM Matīss Treinis 
> wrote:
>
>> Yes, just to clarify the scope of my initial proposal, this should only
>> ever apply to promoted constructors that have 1 or more promoted
>> parameters, and no not-promoted parameters.
>>
>> These would NOT be considered valid:
>>
>> public function __construct(
>> private Baz $baz,
>> Bar $bar
>> );
>>
>> public function __construct();
>>
>> public function __construct(Baz $baz);
>>
>> as well as anything not related to __construct.
>>
>> - Matīss
>>
>
> I've put up a quick implementation for this:
> https://github.com/php/php-src/pull/6972
>
> As this seems somewhat controversial, I'm afraid this change will have to
> go through the RFC process.
>
> Nikita
>
>
>> On Tue, May 11, 2021 at 10:58, Nikita Popov  wrote:
>>
>> On Mon, May 10, 2021 at 10:29 AM Matīss Treinis 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> Since constructor property promotion is now implemented, and it looks
>>> like it could become a widely used feature, I am proposing a small,
>>> cosmetic change in syntax for constructors in concrete classes to do
>>> away with empty constructor body.
>>>
>>> Here's an example of how this would work:
>>>
>>> >> namespace App;
>>>
>>> class Foo {
>>> public function __construct(
>>> private Bar $bar,
>>> private Baz $baz
>>> );
>>> }
>>>
>>> Some notes to this:
>>>
>>> - Since this is similar to already existing syntax for body-less
>>> methods, parser should not be affected that much. I hope. I really have
>>> no idea.
>>> - Syntax would be optional - meaning, you can as well continue using
>>> empty body, just that in this case the body would be implied empty.
>>>
>>> Thoughts?
>>> Regards,
>>> - Matīss
>>>
>>
>> For what it's worth, I've received the same suggestion from quite a few
>> people. There seems to be an intuitive expectation that only adding a
>> semicolon will work in this case. Personally, I'm okay with allowing it.
>>
>> If we allow it, I would restrict it to specifically the case of a) a
>> promoted constructor b) which has *only* promoted parameters. I don't think
>> we should allow replacing "{}" with ";" for methods in the general case.
>>
>> Regards,
>> Nikita
>>
>>

Re: [PHP-DEV] [RFC] New in initializers

[Rowan Tommins]

On 11/05/2021 14:12, Dik Takken wrote:

So the use of "new" in initializers would require extending this base
class and call the parent constructor. Maybe forgetting to do so could
throw, preventing initializers from silently not working.



If we managed to get that working, I wonder if we could also include a 
check for uninitialized typed properties, a bit like Swift's "two-phase 
initializers". In short, make this throw an error:


class Foo extends \PHP\Base {
    private Logger $logger;

    public function __construct() {
    parent::construct(); // "Error: Property $logger has no default 
and was not initialized before calling Base constructor"

    }
}

This would catch bugs closer to their source, where currently there is 
no error until $logger is accessed.



However, the "if" at the beginning of this message is quite a big one: 
it's not obvious where to assert any of this, because the constructor is 
just called as a normal method *after* the engine considers the object 
to be "created".



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] New in initializers

[Dik Takken]

On 11-05-2021 11:56, Nikita Popov wrote:
> 
> An issue for using new in (non-static) properties is that these objects are
> going to get created even if the constructor doesn't run. This could be a
> problem for things like unserialize() and anything that implements related
> functionality in userland (e.g. Symfony's VarCloner). In particular, this
> means that the default is *always* going to be constructed and populated,
> even if you're bypassing the constructor. Of course, this also happens with
> other property defaults, but in this case object construction may be more
> expensive (and possibly side-effecting). That's not great, and there
> wouldn't really be any way to avoid that.

That sounds like a bad situation to me.

> The alternative would be to instead only initialize such properties in the
> constructor, which comes with its own caveats: We'd have to make all
> classes actually have a constructor, and you'd have to make sure to call
> parent::__construct() even if there is no explicit parent constructor,
> otherwise you might be missing some property initializations. This also
> causes something of an asymmetry between "simple" default values
> (initialized on object creation) and "complex" defaults (initialized during
> constructor call).

The requirement of having to call the parent constructor would start
making sense in case we had a built-in base class that represents all of
the features that any PHP class has by default, including a constructor.
This class could act like an explicit base class that you can extend in
order to inherit the property initialization feature.

The idea is similar to the so called new style classes in Python where
you extend "object". This base class basically contains default
implementations of magic methods like __init__().

So the use of "new" in initializers would require extending this base
class and call the parent constructor. Maybe forgetting to do so could
throw, preventing initializers from silently not working.


Regards,
Dik Takken

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Discussion: Object-scoped RNG

[Go Kudo]

Hi internals.

I previously proposed an object scope RNG implementation inside.
However, the RFC was rejected after a vote.

https://wiki.php.net/rfc/object_scope_prng

Vote: https://externals.io/message/113888
Discussion: https://externals.io/message/112819

As per my previous proposal, PHP is currently in a very unclear state
regarding the random number implementation.

So I would like to ask a few questions.

- Do you think that PHP needs an object-scoped random number
implementation? And why?
- If the API in the previous RFC was improved and voted on again, would you
be willing to vote for it?
- What issues do you think should have been resolved between proposal and
ballot in the previous RFC?

I would like a variety of opinions.

Translated with www.DeepL.com/Translator (free version)

Regards,
Go Kudo

Re: [PHP-DEV] [RFC] Deprecate ticks

[Ayesh Karunaratne]

>
> Hi Nikita,
>
> wt., 11 maj 2021 o 10:53 Nikita Popov  napisał(a):
>
> > Hi internals,
> >
> > I'd like to propose the depreciation of the ticks mechanism:
> > https://wiki.php.net/rfc/deprecate_ticks
> >
> > I'm submitting this separately from the PHP 8.1 deprecations RFC, as this
> > is a language change, even if not a particularly important one...
> >
>
> Glad to see this topic. That's a YES
>
> Cheers,
> Michał Marcin Brzuchalski

I agree too.

I can't think of use cases with ticks, other than signal handling or
profiling code. We already have better tooling for both of them.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate ticks

[Sebastian Bergmann]

Am 11.05.2021 um 11:13 schrieb Michał Marcin Brzuchalski:

Glad to see this topic. That's a YES 👍


I second that emotion.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] VCS Account Request: nnyves

[Yves Ndagijimana]

Maintaining php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Bruce Weirdan]

> If we allow it, I would restrict it to specifically the case of a) a
> promoted constructor b) which has *only* promoted parameters. I don't think
> we should allow replacing "{}" with ";" for methods in the general case.

It could also be useful when you want to make sure constructor is
*not* defined, e.g.
```
private final function __construct();
```
(often seen in singleton implementations).

-- 
  Best regards,
  Bruce Weirdan mailto:weir...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Nikita Popov]

On Tue, May 11, 2021 at 12:17 PM Matīss Treinis  wrote:

> Yes, just to clarify the scope of my initial proposal, this should only
> ever apply to promoted constructors that have 1 or more promoted
> parameters, and no not-promoted parameters.
>
> These would NOT be considered valid:
>
> public function __construct(
> private Baz $baz,
> Bar $bar
> );
>
> public function __construct();
>
> public function __construct(Baz $baz);
>
> as well as anything not related to __construct.
>
> - Matīss
>

I've put up a quick implementation for this:
https://github.com/php/php-src/pull/6972

As this seems somewhat controversial, I'm afraid this change will have to
go through the RFC process.

Nikita


> On Tue, May 11, 2021 at 10:58, Nikita Popov  wrote:
>
> On Mon, May 10, 2021 at 10:29 AM Matīss Treinis 
> wrote:
>
>> Hi everyone,
>>
>> Since constructor property promotion is now implemented, and it looks
>> like it could become a widely used feature, I am proposing a small,
>> cosmetic change in syntax for constructors in concrete classes to do
>> away with empty constructor body.
>>
>> Here's an example of how this would work:
>>
>> > namespace App;
>>
>> class Foo {
>> public function __construct(
>> private Bar $bar,
>> private Baz $baz
>> );
>> }
>>
>> Some notes to this:
>>
>> - Since this is similar to already existing syntax for body-less
>> methods, parser should not be affected that much. I hope. I really have
>> no idea.
>> - Syntax would be optional - meaning, you can as well continue using
>> empty body, just that in this case the body would be implied empty.
>>
>> Thoughts?
>> Regards,
>> - Matīss
>>
>
> For what it's worth, I've received the same suggestion from quite a few
> people. There seems to be an intuitive expectation that only adding a
> semicolon will work in this case. Personally, I'm okay with allowing it.
>
> If we allow it, I would restrict it to specifically the case of a) a
> promoted constructor b) which has *only* promoted parameters. I don't think
> we should allow replacing "{}" with ";" for methods in the general case.
>
> Regards,
> Nikita
>
>

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Matīss Treinis]

Yes, just to clarify the scope of my initial proposal, this should only 
ever apply to promoted constructors that have 1 or more promoted 
parameters, and no not-promoted parameters.


These would NOT be considered valid:

   public function __construct(
   private Baz $baz,
   Bar $bar
   );

   public function __construct();

   public function __construct(Baz $baz);

as well as anything not related to __construct.

- Matīss

On Tue, May 11, 2021 at 10:58, Nikita Popov  
wrote:
On Mon, May 10, 2021 at 10:29 AM Matīss Treinis > wrote:

Hi everyone,

 Since constructor property promotion is now implemented, and it 
looks

 like it could become a widely used feature, I am proposing a small,
 cosmetic change in syntax for constructors in concrete classes to do
 away with empty constructor body.

 Here's an example of how this would work:

  methods, parser should not be affected that much. I hope. I really 
have

 no idea.
 - Syntax would be optional - meaning, you can as well continue using
 empty body, just that in this case the body would be implied empty.

 Thoughts?
 Regards,
 - Matīss


For what it's worth, I've received the same suggestion from quite a 
few people. There seems to be an intuitive expectation that only 
adding a semicolon will work in this case. Personally, I'm okay with 
allowing it.


If we allow it, I would restrict it to specifically the case of a) a 
promoted constructor b) which has *only* promoted parameters. I don't 
think we should allow replacing "{}" with ";" for methods in the 
general case.


Regards,
Nikita

Re: [PHP-DEV] [RFC] New in initializers

[Nikita Popov]

On Fri, Mar 19, 2021 at 2:02 PM Nikita Popov  wrote:

> On Fri, Mar 19, 2021 at 12:57 PM Nikita Popov 
> wrote:
>
>> On Fri, Mar 19, 2021 at 12:22 PM Nikita Popov 
>> wrote:
>>
>>> On Wed, Mar 3, 2021 at 7:04 PM Alexandru Pătrănescu 
>>> wrote:
>>>

 On Wed, Mar 3, 2021 at 5:49 PM Nikita Popov 
 wrote:

> On Wed, Mar 3, 2021 at 4:28 PM Alexandru Pătrănescu <
> dreal...@gmail.com> wrote:
>
>> Hi,
>>
>> This looks very nice and I'm interested in further steps where not
>> only new can be used :).
>>
>> The only thing I think it would be good to improve is to have a
>> deterministic order for running initialization.
>> Yes, this can be done at a later point, I guess. But maybe there is
>> already an order of initialization right now and people would start
>> replying on it and it would be good to mention it.
>> Or maybe I didn't understand what this refers to: "this is not
>> guaranteed behavior, and code should not rely on a specific point of
>> evaluation."
>>
>
> Which particular cases would you like to see specified? There are five
> cases that have clearly defined behavior, and that I could explicitly
> specify if desired:
>
>  * Non-class constants: Are evaluated immediately when declared (i.e.
> when control flow reaches the declaration).
>  * Attribute arguments: Are evaluated in the order of the arguments.
>  * Parameter defaults: Are evaluated in the order of the parameters.
>  * Non-static property defaults: Are evaluated in order of
> declaration, with parent properties first. The constructor is run after
> defaults are evaluated.
>  * Static variables: Are evaluated immediately when declared (i.e.
> when control flow reaches the declaration).
>
> And then there are the two problematic cases: Class constants and
> static properties. Currently, PHP evaluates these semi-lazily. All class
> constants and static properties are evaluated at the same time, on first
> "use" of the class. I would consider this to be something of an
> implementation detail. That's what I meant by that sentence.
>
> Now, if we allow "new" expressions, then I could see an argument in
> favor of requiring class constant and static property initializers to be
> evaluated eagerly, i.e. directly after the class has been declared. This
> would be a (minor) backwards-compatibility break, because invalid
> constant/property declarations would error out immediately, even if they
> don't get used. However, I do think that this would be the most 
> predictable
> behavior once potentially side-effecting expressions are involved (we
> already support side-effecting expressions right now, but less 
> explicitly).
>
>
 Yes, this is what I was thinking about, to have a clear stated order of
 initialization.
 Yes, I agree that class constants and static properties should be
 eagerly declared when class is declared.

 So the order would be:
 - constants and static variables, when reaching the statement that does
 the declaration
 - class constants and static property, when class is declared, in order
 of their declaration in the class
 - instance property, when class is instantiated, in order of their
 declaration in the class, before construct
 - parameter defaults and attribute arguments defaults, when
 function/method/attribute construct is called, in order of the declared
 parameter/arguments.

 That sounds good to me.
 Thanks!
  Alex

>>>
>>> I've updated the RFC (and implementation) to evaluate class constants
>>> and static properties at time of class declaration. As such, everything
>>> should have a well-defined evaluation order now.
>>>
>>> However, this also means that this RFC now also contains a
>>> backwards-compatibility break: Anything used inside class constant / static
>>> property initializers needs to actually be available at the time the class
>>> is declared. You can't first declare the class, then declare some
>>> additional constants it uses, and then use it.
>>>
>>
>> Another complication here is preloading. The current semantics of
>> evaluation on first use work well there, because class loading (during
>> preloading) is decoupled from evaluation (during request). Now, we can't
>> evaluate initializers during "opcache_compile_file" style preloading, so
>> we'd have to delay this to the start of the request. And then we'd have to
>> evaluate initializers for all preloaded classes, regardless of whether they
>> will be used in this particular request or not. Also opens up the question
>> of the order in which the classes should be evaluated.
>>
>> I initially liked the idea of evaluating everything at the time of class
>> declaration, but now get the impression that this causes more problems than
>> it solves, and we should go

Re: [PHP-DEV] [RFC] Deprecate ticks

[Michał Marcin Brzuchalski]

Hi Nikita,

wt., 11 maj 2021 o 10:53 Nikita Popov  napisał(a):

> Hi internals,
>
> I'd like to propose the depreciation of the ticks mechanism:
> https://wiki.php.net/rfc/deprecate_ticks
>
> I'm submitting this separately from the PHP 8.1 deprecations RFC, as this
> is a language change, even if not a particularly important one...
>

Glad to see this topic. That's a YES 👍

Cheers,
Michał Marcin Brzuchalski

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Nikita Popov]

On Mon, May 10, 2021 at 10:29 AM Matīss Treinis  wrote:

> Hi everyone,
>
> Since constructor property promotion is now implemented, and it looks
> like it could become a widely used feature, I am proposing a small,
> cosmetic change in syntax for constructors in concrete classes to do
> away with empty constructor body.
>
> Here's an example of how this would work:
>
>  namespace App;
>
> class Foo {
> public function __construct(
> private Bar $bar,
> private Baz $baz
> );
> }
>
> Some notes to this:
>
> - Since this is similar to already existing syntax for body-less
> methods, parser should not be affected that much. I hope. I really have
> no idea.
> - Syntax would be optional - meaning, you can as well continue using
> empty body, just that in this case the body would be implied empty.
>
> Thoughts?
> Regards,
> - Matīss
>

For what it's worth, I've received the same suggestion from quite a few
people. There seems to be an intuitive expectation that only adding a
semicolon will work in this case. Personally, I'm okay with allowing it.

If we allow it, I would restrict it to specifically the case of a) a
promoted constructor b) which has *only* promoted parameters. I don't think
we should allow replacing "{}" with ";" for methods in the general case.

Regards,
Nikita

[PHP-DEV] [RFC] Deprecate ticks

[Nikita Popov]

Hi internals,

I'd like to propose the depreciation of the ticks mechanism:
https://wiki.php.net/rfc/deprecate_ticks

I'm submitting this separately from the PHP 8.1 deprecations RFC, as this
is a language change, even if not a particularly important one...

Regards,
Nikita

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Kalle Sommer Nielsen]

Den tir. 11. maj 2021 kl. 00.52 skrev Kamil Tekiela :
> Could we please change this rule or at least stop enforcing it?
> Do people actually have mail clients that don't automatically hide the
> previous conversation? If not, then I think we can let people top-post.

-1. I feel the same as Stas does here.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Pierre]

Le 10/05/2021 à 23:51, Kamil Tekiela a écrit :

Hi Internals,

Could we drop the bottom-posting rule?
I'm opposed to dropping the bottom-posting rule, for the simple reason 
that you naturally read from top to bottom, and most people don't bother 
reading again the whole thread when they read a single answer.

Mail clients don't make it easy for us; it's hidden by default.

Thunderbird doesn't hide anything.

Bottom-posting makes reading the thread much more difficult too. The actual 
reply gets lost in between the
quoted content.
It's in natural reading order, most people do post trimming as well, 
which mean that they remove useless text and keep only quotes they reply 
to, which makes it even more natural to read.

Many modern clients are designed to handle top-posting and don't
handle bottom-posting well.
Not all mail clients, personally Thunderbird is a modern client, at 
least as modern as are the others, and mine does bottom-post per default.

If you want to quote someone then it makes sense to copy a part of the
message and then add a reply below

Yes, that's the way !

forcing people to remove the default reply from the mail client and then add 
the whole previous message
on top of your own reply isn't very productive. It wastes time and screen space.
Then you mail client is evil and fights against you if it forces you to 
copy paste and rearrange.

Regards,
Kamil


Regards,

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Marco Pivetta]

Sure, why not: email clients are decent enough to hide quoted sections
anyway 👍

Heck, even my phone can read top-posts, and the rest of the folks (reddit,
mostly) use https://externals.io/ anyway 🤷

Feel free to call me out for top-posting this 😛

On Mon, May 10, 2021, 23:52 Kamil Tekiela  wrote:

> Hi Internals,
>
> Could we drop the bottom-posting rule?
>
> Almost all new contributors fall into this trap and reply to a thread by
> top-posting, only to get chastised by someone else on the list. It's really
> difficult to remember to delete the default reply. Mail clients don't make
> it easy for us; it's hidden by default. Bottom-posting makes reading the
> thread much more difficult too. The actual reply gets lost in between the
> quoted content. I often get confused about what is new and what was
> quoted. Many modern clients are designed to handle top-posting and don't
> handle bottom-posting well. People are usually used to it and they read
> from top to bottom. I don't know if in the past some mail clients defaulted
> to bottom-posting but right now it just seems like an unnecessary
> annoyance.
>
> If you want to quote someone then it makes sense to copy a part of the
> message and then add a reply below, but forcing people to remove the
> default reply from the mail client and then add the whole previous message
> on top of your own reply isn't very productive. It wastes time and screen
> space.
>
> Could we please change this rule or at least stop enforcing it?
> Do people actually have mail clients that don't automatically hide the
> previous conversation? If not, then I think we can let people top-post.
>
> Regards,
> Kamil
>