Discussion Short Constructor

Hi,

I've found a discussion about Records
https://externals.io/message/125975 and found a one key point which I
really like in Kotlin (hello): short constructors.

Rob said that short constructor will be probably removed:

1. Inline constructor isn’t necessary and could be proposed separately. I’ve thought recently about this feature
   I will probably remove this, to be honest. It was for nesting records
   inside classes or other records, but this feature was declined, so
   there isn't really a need for it.

Whether it's true or not I've played with syntax analyser and created a
sugared polyfill for short constructors:
https://github.com/php/php-src/pull/19133

Many examples of how it works inside the PR, just read them.

Should I propose the RFC or not?

This step move us further to "light" structures or "heavy" structures
written "simple":

class RedBox extends Box(width: 50, height: 200);

$box = new RedBox();

instead of

class RedBox extends Box {
public function __construct()
{
parent::__construct(width: 50, height: 200);
}
}

OR

class RedBox extends Box {
public function getWidth(): int
{
return 50;
}

public function getHeight(): int
{
    return 200;
}

}

OR even with Single Expression Functions RFC:

class RedBox extends Box {
public function getWidth(): int => 50;

public function getHeight(): int => 200;

}

--
Best regards,
Dmitrii Derepko.
@xepozz

I have some concerns that there may be edge cases we've not thought about, but at the moment I am generally in favor. An RFC and implementation would likely help ferret out those edge cases.

I agree that this combined with single expression functions would go a long way to making lightweight data structures even easier to create and use.

--Larry Garfield

Hi,

I've found a discussion about Records https://externals.io/message/125975 and found a one key point which I really like in Kotlin (hello): short constructors.

Rob said that short constructor will be probably removed:

1. Inline constructor isn’t necessary and could be proposed separately. I’ve thought recently about this feature
   I will probably remove this, to be honest. It was for nesting records inside classes or other records, but this feature was declined, so there isn't really a need for it.

Whether it's true or not I've played with syntax analyser and created a sugared polyfill for short constructors: https://github.com/php/php-src/pull/19133

Many examples of how it works inside the PR, just read them.

Should I propose the RFC or not?

This step move us further to "light" structures or "heavy" structures written "simple":

class RedBox extends Box(width: 50, height: 200);

$box = new RedBox();

instead of

class RedBox extends Box {
public function __construct()
{
parent::__construct(width: 50, height: 200);
}
}

OR

class RedBox extends Box {
public function getWidth(): int
{
return 50;
}

public function getHeight(): int
{
    return 200;
}

}

OR even with Single Expression Functions RFC:

class RedBox extends Box {
public function getWidth(): int => 50;

public function getHeight(): int => 200;

}

--
Best regards,
Dmitrii Derepko.
@xepozz

Hi Dmitrii,

I meant that I'd remove it from the records RFC, not that I wouldn't ever pick it up. In fact, I put it on my todo list and announced it to this list, 7 months ago: https://externals.io/message/125975#126029

Fun fact: it was a part of my original proposal with nested classes that then got removed due to feedback.

Why I haven't proposed it as a separate RFC: with PSR-4 being so popular, nobody is going to write one-line files to take advantage of this. Thus, when I was going to revisit nested classes later this year (after all the release shenanigans and some personal issues), I was planning to add this feature to the nested class v2 RFC (again). A lot of feedback I got on nested classes was "when would I use this?" -- and I suspect that would be a lot of the feedback you'd get here (see: PSR-4). I'm more convinced than ever that short constructors and nested classes create a chicken-and-egg problem. They only really make sense together; at least with our current coding conventions and standards. It will create a longer discussion period, but that's fine, IMHO.

If you'd like to continue with this RFC, I'd love to discuss it further with you and help you out. I believe it is a bit more than "just" syntax sugar, but I'd have to dig out my records implementation.

— Rob