Hi internals,

I would like to submit the following RFC for your consideration:
https://wiki.php.net/rfc/constructor_promotion

Big fan. Thanks for this.

--
Paul M. Jones
pmjones@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

Am 26.03.2020 um 14:30 schrieb Nikita Popov:

I would like to submit the following RFC for your consideration:
https://wiki.php.net/rfc/constructor_promotion

Looks good to me! Thanks.

I would like to submit the following RFC for your consideration:
https://wiki.php.net/rfc/constructor_promotion

This is based on one off the suggestions made in
https://externals.io/message/109220, and some existing discussion on the
topic can be found in that thread.

Similar to an RFC you submitted six years ago:
https://wiki.php.net/rfc/automatic_property_initialization
I think the availability of typed properties makes the syntax for this much
more sensible and I look forward to +1ing it.

-Sara

czw., 26 mar 2020 o 14:31 Nikita Popov nikita.ppv@gmail.com napisał(a):

Hi internals,

I would like to submit the following RFC for your consideration:
https://wiki.php.net/rfc/constructor_promotion

This is based on one off the suggestions made in
https://externals.io/message/109220, and some existing discussion on the
topic can be found in that thread.

As I already said in linked topic. IMHO this is wrong and can be easily
overused.

A list of properties is changed into a list of constructor method arguments
which
can be easily overused on long argument lists and when the time comes to
have attributes then the list of promoted arguments with their annotations
and some extra blank lines then to improve readability could lead to
long constructor signature list on a different level of indentation which
also then always has to be un-collapsed in IDE and on the top of a class to
keep the track of properties where usually list of properties exists with
additional named constructors (always at the top).

Not even mentioning that mix of promoted and un-promoted argument list
would just feel awkward and that kind of mixed constructor where some of
arguments are assigned magically and some of them not can make it harder to
read.

And I'm not saying this cause I'm preparing another proposal for filling
the gap
between the use of ad-hoc array structures, and the use of well-defined and
type-safe value types.
I'm saying this because PHP was always verbose and easy to read/decipher
this solution IMHO has more drawbacks regarding readability than benefits.

Cheers,

Michał Brzuchalski

Hi internals,

I would like to submit the following RFC for your consideration:
https://wiki.php.net/rfc/constructor_promotion

This is based on one off the suggestions made in
https://externals.io/message/109220, and some existing discussion on the
topic can be found in that thread.

The primary motivation for this feature is to close the currently rather
wide gap between the use of ad-hoc array structures, and the use of
well-defined and type-safe value objects. The latter is what we want people
to use, but the former is, unfortunately, what is easy to use.

Will this cause any problems with ReflectionClass? (I’m assuming not, but wanted to ask anyway.)

Cheers,
Ben

Hi!

I would like to submit the following RFC for your consideration:
https://wiki.php.net/rfc/constructor_promotion

I like this shortcut. I am not sure though I understand why callable is
not allowed? Can't it just create a non-typed property?

--
Stas Malyshev
smalyshev@gmail.com

Hi,

I would like to submit the following RFC for your consideration:
https://wiki.php.net/rfc/constructor_promotion

This is based on one off the suggestions made in
https://externals.io/message/109220, and some existing discussion on the
topic can be found in that thread.

The primary motivation for this feature is to close the currently rather
wide gap between the use of ad-hoc array structures, and the use of
well-defined and type-safe value objects. The latter is what we want people
to use, but the former is, unfortunately, what is easy to use.

The amount of boilerplate this would cut down for e.g. projects using DI
and DTOs is unfathomable.

How does this work together with reflection? Will reflection see the
properties and the extended constructor definitions?

thanks,

• Markus

I would like to submit the following RFC for your consideration:
https://wiki.php.net/rfc/constructor_promotion

I love it :)

Just one question:
Shouldn't default values be copied on the signature? That would be expected
for me.
(and that would make the properties still initialized when child classes
don't call the parent constructor for whatever reasons.)

class Point {
public function __construct(
public float $x = 0.0,

<==>

class Point {
public float $x = 0.0;

public function __construct(
    float $x = 0.0,

Nicolas

Hi internals,

I would like to submit the following RFC for your consideration:
https://wiki.php.net/rfc/constructor_promotion

This is based on one off the suggestions made in
https://externals.io/message/109220, and some existing discussion on the
topic can be found in that thread.

The primary motivation for this feature is to close the currently rather
wide gap between the use of ad-hoc array structures, and the use of
well-defined and type-safe value objects. The latter is what we want people
to use, but the former is, unfortunately, what is easy to use.

As the reception has been positive, I plan to open voting on this proposal
soon. Please tell me if you have further concerns or the RFC needs
additional clarification.

Regards,
Nikita

Hi internals,

I would like to submit the following RFC for your consideration:
https://wiki.php.net/rfc/constructor_promotion

This is based on one off the suggestions made in
https://externals.io/message/109220, and some existing discussion on the
topic can be found in that thread.

The primary motivation for this feature is to close the currently rather
wide gap between the use of ad-hoc array structures, and the use of
well-defined and type-safe value objects. The latter is what we want people
to use, but the former is, unfortunately, what is easy to use.

As it looks like the Attributes RFC is going to be accepted, we need to
consider how it will interact with this proposal. I've added an extra
section for this: https://wiki.php.net/rfc/constructor_promotion#attributes

The problem is that attributes are allowed both on properties and on
parameters. For promoted properties, what does the attribute apply to? My
original suggestion was to make it apply to both the parameter and the
generated property. However, Benjamin pointed out that an attribute on a
promoted property is almost certainly intended to apply to the property
only, especially because parameter attributes have not been supported
historically (in phpdoc). Applying it to both the property and the
parameter may cause issues for attributes that want to strictly validate
where they are used.

I think the best answer to this question may be to forbid the use of
attributes on promoted properties entirely, because there is no unambiguous
interpretation for them. I also think that using attributes pushes this
"syntax sugar" to its limit, as you can easily end up with a 50 line
constructor signature that way, at least if I'm going by some of the more
involved uses of annotations...

Does anyone have thoughts on this?

Regards,
Nikita

Hi internals,

I would like to submit the following RFC for your consideration:
https://wiki.php.net/rfc/constructor_promotion

This is based on one off the suggestions made in
https://externals.io/message/109220, and some existing discussion on the
topic can be found in that thread.

The primary motivation for this feature is to close the currently rather
wide gap between the use of ad-hoc array structures, and the use of
well-defined and type-safe value objects. The latter is what we want people
to use, but the former is, unfortunately, what is easy to use.

Regards,
Nikita

I am rather concerned about constructor promotion will result in some complex "single" lines of code that all must be syntactically correct for any of it to be syntactically correct. It will make it more challenging to read and write code as we add attributes and PHP doc to properties. And if we still have to deal with concern that parameter names that were previously never indented to become part of the API will be exposed as part of the API, with potential breakage when name changes.

Pondering these issues I think I have a very simple proposal that would address most (all?) of the concerns I am aware for both Constructor Property Promotion and Named Parameters.

Consider simply what we might call "Parameter Blocks." Since PHP always expects a parentheses to follow the function or method name it should be possible to opt-in replace it with a brace-enclosed block of parameters instead since it would be unambiguous and this no conflict, and no need for new keywords.

The following illustrates how it my be used by repurposing an example from the RFC:

abstract class Node {
public function __construct{
/**
* @param Location|null — The starting location for this abstract node
*/
Location $startLoc = null;

    protected Location $startLoc = null;

	/**
	 * @param Location|null — The ending location for this abstract node
	 */
    protected Location $endLoc = null;
} {}

}

class ParamNode extends Node {
public function __construct{
/**
* @param string $name — Names this Node.
*/
public string $name;

	/**
	 * @param ExprNode|null $default — Contains the expression this node represents 
	 */
    <<ORM\Entity("exprNode")>>
    public ExprNode $default = null;

	/**
	 * @param TypeNode|null $type — Contains the type expected for this node's expression
	 */
    <<ORM\Entity("typeNode")>>
    public TypeNode $type = null;

	/**
	 * @param bool $byRef — True if this node is a reference, false otherwise
	 */
    public bool $byRef = false;

	/**
	 * @param bool $byRef — True if this node is variadic, false otherwise
	 */
    public bool $variadic = false;

	/**
	 * @param Location|null — The starting location for this node
	 */
    Location $startLoc = null;

	/**
	 * @param Location|null — The ending location for this node
	 */
    Location $endLoc = null;
} {
    parent::__construct($startLoc, $endLoc);
}

}

Envision how that same code would have to be written if all as part of the single "line" contained within the parenthesis of a programming language?

As far as I can tell this is a clean and elegant approach with many fewer downsides than those that have been discussed thus far. I hope that each of you reading this will seriously consider this is viable alternative option.

-Mike

Hi internals,

I would like to submit the following RFC for your consideration:
https://wiki.php.net/rfc/constructor_promotion

This is based on one off the suggestions made in
https://externals.io/message/109220, and some existing discussion on the
topic can be found in that thread.

The primary motivation for this feature is to close the currently rather
wide gap between the use of ad-hoc array structures, and the use of
well-defined and type-safe value objects. The latter is what we want people
to use, but the former is, unfortunately, what is easy to use.

Regards,
Nikita

I know I said it a few times already, but ... I plan to start voting on
this soon. There has been some additional discussion recently on
alternative syntax/approaches, such as Mike's parameter blocks, and Larry's
"promoted" keyword. I wasn't really convinced by either of those, so I plan
to go forward with the proposal as is.

Nikita