Hi,
[Proposal]
Allow interfaces to define properties. The implementing class must
have the same properties with the same name/type.
As the goal of the interfaces is to define the public "surface" of
the implementing class, I think that the public properties are also
part of that.
[Use case] - tl;dr;
Right now I’m working on a product configurator. The input I get, I
turn them into ValueObjects in the initial phase of the request. Then
later based on some conditions, I turn them in a deterministic but
very varying order into another ValueObject which has the same
properties, but all of them are readonly. I tried to create somehow
the same: https://3v4l.org/Vb7fE#v8.2.4 There are places where I
have an array with a mix of them and I want to access the $id or
$axisOrientation. I also have methods on them. I know an
abstract class could do this for me but I feel that this would be the
most accurate way to define what I want.
[Example]
interface Vehicle {
public int $serialNumber;
public function drive(): void;
}
/*
* This would lead to an error, something like:
* Class Car contains 1 abstract property and must therefore be
* declared abstract or implement the remaining property
* (Vehicle::$serialNumber)
*/
class Car implements Vehicle {
public function drive() : void { }
}
// This would lead to an error too, because the type is different.
class Bike implements Vehicle {
public string $serialNumber;
public function drive() : void { }
}
// This would lead to an error too. The rule for readonly properties
// would be the same as right now between normal classes.
class Bike implements Vehicle {
public readonly string $serialNumber;
public function drive() : void { }
}
[Implementation]
Personally I don’t have experience in php internal development.
I do have C++ / some C experience. I'm going through the PHP
Internals book and every possible tutorial I find. I definitely would
like to take part in it, and I'm planning to do more later.
--
Bests
Zoltán Fekete
Hi,
[Proposal]
Allow interfaces to define properties. The implementing class must
have the same properties with the same name/type.As the goal of the interfaces is to define the public "surface" of
the implementing class, I think that the public properties are also
part of that.
This is a part of the "Property Hooks" RFC that Ilija and are working on. It's not quite done yet, but it's mostly there. The draft is available here: https://wiki.php.net/rfc/property-hooks
The main thing we still have to sort out is serialization handling. Everything else is pretty well stable, including defining properties asymmetrically in interfaces.
We hope to have it finalized and ready for discussion within the next month-or-less. (Fingers crossed.)
--Larry Garfield
On Thu, Mar 30, 2023 at 3:50 PM Larry Garfield larry@garfieldtech.com
wrote:
This is a part of the "Property Hooks" RFC that Ilija and are working on.
It's not quite done yet, but it's mostly there. The draft is available
here: https://wiki.php.net/rfc/property-hooks
Do you think we could have a smaller RFC that only deals with properties in
interfaces that are just like what's allowed in classes right now, public
and public readonly?
The need seems to be: a readonly property in classes and a interface that
signals a get-only access so maybe readonly flag on interface attribute is
clear.
Or maybe that can be attempted to be achieved in the same rfc and we
fallback to a smaller RFC for the interface only in cases property-hooks
RFC does not pass?
Thank you,
Alex
On Thu, Mar 30, 2023 at 3:50 PM Larry Garfield larry@garfieldtech.com
wrote:This is a part of the "Property Hooks" RFC that Ilija and are working on.
It's not quite done yet, but it's mostly there. The draft is available
here: https://wiki.php.net/rfc/property-hooksDo you think we could have a smaller RFC that only deals with properties in
interfaces that are just like what's allowed in classes right now, public
and public readonly?
The need seems to be: a readonly property in classes and a interface that
signals a get-only access so maybe readonly flag on interface attribute is
clear.
Not really. For the hook-friendly version, we need to be able to separate get and set requirements. Hence:
interface I
{
public string $foo { get; }
}
But separate get/set requirements is not a feature that exists today, since asymmetric visibility didn't pass. So that would mean either including syntax that does nothing but hopefully will in the future if something else passes, OR leaving that part out:
interface I
{
public string $foo;
}
which then wouldn't work (or at least not as well) if/when hooks or asymmetric visibility get added later.
As for readonly, the more I've worked with it the more I think readonly is fundamentally broken. Trying to use that as a "get only" syntax now would be confusing, or restrict the property in ways the interface shouldn't. (Because it would require the property to be readonly, which has all kinds of other implications the class may not want.) And then it would be confusing if we DO add hooks or asymmetric visibility in the future, which would need to use the { get; set; } syntax, but now you also have readonly in there, so how does that interact?
The best answer that leaves the least confusing cruft lying around the language causing problems is to do hooks and interface properties together, so they can be complementary. We considered doing interface properties separately as a third RFC, but in practice they're most useful if there are hooks available so decided to just combine them.
This is one of those cases where our lack of roadmap and planning capability really kneecaps PHP's ability to evolve cleanly. And we really don't want to make the same mistake as readonly, where doing the "junior version" first actually makes doing the full version harder, not easier.
--Larry Garfield
On Thu, Mar 30, 2023 at 3:50 PM Larry Garfield larry@garfieldtech.com
wrote:This is a part of the "Property Hooks" RFC that Ilija and are working on.
It's not quite done yet, but it's mostly there. The draft is available
here: https://wiki.php.net/rfc/property-hooksDo you think we could have a smaller RFC that only deals with properties
in
interfaces that are just like what's allowed in classes right now, public
and public readonly?
The need seems to be: a readonly property in classes and a interface that
signals a get-only access so maybe readonly flag on interface attribute is
clear.
Hey,
So I just recently joined the mailing list, and in another discussion I
read something about
how to answer properly. I hope I didn't mess it up.
So read the RFC, and that is waaay more extensive. And as I'm just starting
to participate I
cannot really add more to than: as far as my experience goes, I think a
smaller RFC
would not really be compatible with that. And I think that just renders
mine "closed", being
already in progress.
Anyways: I was about to ask - but then I forgot - is there any up-to-date
documentation /
tutorial besides https://www.phpinternalsbook.com/. I found some from some
blog, but then
I saw that they are at least 10 years old.
Mit freundlichen Grüßen / Best regards
Zoltán Fekete