On Mon, Mar 23, 2020 at 1:48 AM Larry Garfield <la...@garfieldtech.com> wrote:
> Hi folks. > > There have been a lot of RFCs and possible RFCs of late that are all > circling around the same related problem space: Working with objects right > now involves too much boilerplate to get things done. As I've mentioned > several times, I believe we need to be looking for broader solutions rather > than narrowly-focused one-offs. > > To that end, I have written an extensive analysis of the problem space and > the current and recent proposals. I've put it on my blog rather than > inline here because it's quite long and the blog offers better formatting. > > Discussion can happen here, but I'll also respond to comments there. > > In short: I believe our biggest potential win is to focus on 3 RFCs: > > * Constructor Promotion > * Named parameters > * Compound Property Visibility > > For details, see the full writeup: > > https://hive.blog/php/@crell/improving-php-s-object-ergonomics > > Thank you for your attention. > Thanks for the write-up Larry. I like where you're going with this. If we were starting from a blank slate design, I would advocate for: a) having an object initializer syntax b) not having first-class constructors at all c) using named constructors instead. This also happens to be exactly what Rust does, go figure... Unfortunately this kind of approach is hard to retrofit into PHP, because we already have constructors, almost all classes define them, and it's hard to reconcile object initialization syntax and non-trivial constructors in a meaningful way. Combining this with the "no public properties" cargo cult we have inherited from Java, the paradigm shift is probably too large here. If we can't have object initializers, then improving what we can do with constructors is the next best thing :) I generally like the ideal of combining property declaration and constructors. I've had this on my mind for a while already, and also received the same suggestion from a couple of other people (I think Nicolas was one of them?) The current amount of boilerplate that is needed is just large enough that I will often go with a quick and simple ad-hoc array structure rather than declaring an explicit value object type. The main concern, as others have already mentioned, is that these inline declarations can end up being quite verbose, especially once attributes get involved. I think I will write up a quick implementation & RFC for this part, as it seems like something we should at least consider in more detail. Named parameters are a pretty tough topic. I think one of the main points of contention is that they make the parameters names part of the API contract, and as such also subject to LSP. Your proposal offers two possible ways to side-step this: First, by making named parameters opt-in with a special syntax {}. Second, by limiting them to constructors. The latter variant still exposes parameter names in the API, but at least does not require their preservation across inheritance, as constructors are excluded from LSP. I'm somewhat torn on this, because it makes named parameters unusable with the very large body of existing methods, and introduces an inconsistency in which methods can use named params and which don't. Regarding the remainder, I think that all of readonly properties, asymmetric visibility and property accessors have their place and value, with some overlap between them. As you already mentioned, the previous property accessors proposal also included asymettric visibility as a special case, and that's how I would introduce it as well. However, I generally think that the main value really is the readonly properties as proposed in the recent RFC. Nowadays, a large fraction of the classes I use are immutable value objects, for which public readonly properties provide a much closer match to the semantics I want. I think that the problem with with-er methods is just that: It's a problem with with-er methods. It's what happens when you try to shove immutability into something that is not actually being used in an immutable manner. Don't pretend things are immutable when they aren't... Regards, Nikita
