Improving PHP's Object Egonomics: A broad analysis

  109220
March 23, 2020 00:47 larry@garfieldtech.com ("Larry Garfield")
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.

-- 
  Larry Garfield
  larry@garfieldtech.com
  109221
March 23, 2020 01:36 internals@lists.php.net ("Levi Morrison via internals")
> In short: I believe our biggest potential win is to focus on 3 RFCs: > > * Constructor Promotion I would vote yes on this, assuming the implementation is sane.
> * Named parameters This one is tricky -- there are tradeoffs of every approach I've seen
proposed. I have an idea for another way to address this space, but it too has drawbacks; there's inherently no free lunch here, I think.
> * Compound Property Visibility What is this last one? I searched for "compound" in the article, but
did not get many hits, none of which described what it actually _is_.
  109245
March 23, 2020 19:03 larry@garfieldtech.com ("Larry Garfield")
Merging some replies together here...

On Sun, Mar 22, 2020, at 8:36 PM, Levi Morrison via internals wrote:
> > In short: I believe our biggest potential win is to focus on 3 RFCs: > > > > * Constructor Promotion > I would vote yes on this, assuming the implementation is sane.
On Mon, Mar 23, 2020, at 12:55 AM, Michał Brzuchalski wrote:
> That still doesn't resolve issue with lot of boilerplate when you deal with > small objects for which public readonly is enough like object-initializer > could. So I'm not sure about my vote here. It does solve only one narrow > situation for me.
The value here is combining constructor promotion with named parameters. Constructor promotion itself is useful for the class implementer, but doesn't help the caller. Named parameters helps the caller, but doesn't really help the class implementer. The combination of both of them together gives us something similar to the object-initializer syntax as a net result, but with many other benefits because it's not a one-off syntax. So with the two of them together, you get: class Point { public function __construct({public int $x, public int $y}); } Which then allows any of these construction mechanisms: $p1 = new Point(5, 7); $p2 = new Point({x: 5, y: 7}); $p3 = new Point({y: 7, x: 5}); All of which result in an object you can use the same way: print $p1->x . ', '. $p1->y;
> > * Named parameters > This one is tricky -- there are tradeoffs of every approach I've seen > proposed. I have an idea for another way to address this space, but it > too has drawbacks; there's inherently no free lunch here, I think.
Please share. I make no claim of being fully versed in the implementation details of how these would work at the engine level, only at the syntax level.
> > * Compound Property Visibility > What is this last one? I searched for "compound" in the article, but > did not get many hits, none of which described what it actually _is_.
Mm, yeah, I sorta changed names on that part way through. That's the "different visibility for read and for write" proposal that Nicolas mentioned in the readonly thread, for which I borrowed the syntax from the property accessors RFC. On Mon, Mar 23, 2020, at 1:07 AM, Mike Schinkel wrote:
> 1. Your post mentions validation needed for value objects — a concern I > share — but AFAICT your conclusion does not address the issue.
It doesn't directly in a syntactic way. Rather, it allows the constructor and Setter/Wither methods to still exist as now, and users can write what they want in there. That is, it's no change from now. That was one of my evaluation criteria: Improve as many of these as possible without making any of them worse.. This is one were "nothing is made worse".
> 2. It also mentions overlapping concerns and references numerous RFCs, > but there were two other relative works not mentioned. One[1] is an RFC > and the other[2] a PR on Github. I think they both overlaps with this > problem space, with the former addressing validation whereas the latter > case potentially conflicts with constructor promotion.
You are correct, I forgot about the impact of annotations (which I also support). Off hand, I think their only issue would be in relation to the constructor promotion, as the resulting syntax to put a bunch of annotations inside the constructor definition would get... silly. That suggest we may want a different syntax for constructor promotion than what I proposed we borrow from Hack, but I don't think changes the overall argument.
> 1. You don't really address the value object vs. service object > distinction, except on the periphery.
Correct. This also ties into your discussion of Structs/Records as an alternative approach. I have considered that before, but in this writeup.... I found nowhere that any of the possible implementations would be useful only for one or the other. Rather, certain features may be more useful to one or the other but would definitely have uses in both. At the end of the day, I think the only language-level difference between a value and service object is the passing semantics; service objects should pass as they do now, while value objects would, ideally, pass in a way more similar to arrays. However, that was off topic at this time, and not needed. Everything else discussed would be applicable to both object types, so splitting the syntax would not be helpful, just confusing. For instance, property accessor methods on a new Struct type would have the exact same performance issue as they would on a Class today. The goal was to focus on the minimum amount of work we can do to get the maximum benefit, and I don't think a new Struct type would qualify for that.
> 2. You mention the concerns about exposing parameter names as part of > the API but don't address those concerns directly.
I do. Specifically, making named parameters opt-in allows class/function/method authors to decide if they want to make their parameter names part of the API or not. The alternative to support it on all callables period, which is also a viable option but, as noted in the writeup, technically a BC change. Either approach is possible. Now that I think about it, though, named parameters and variadics may not play nicely at all, so we may want to force it to be opt-in only (and incompatible with variadics).
> 3. You mention get/set properties surprisingly running code but do not > address those concerns directly.
That's only an issue with full property accessors, which I specifically do not propose we implement at this time. I was trying to represent the arguments against property accessors last time, as I remembered them; I personally don't think it's a problem and would love to have property accessors exactly as described in the RFC, if the performance issues could be resolved. Since that's not what is being proposed, determining if that's even an issue is not within scope.
> 4. Your concept for a JSON object-like syntax for passing parameter > feels incomplete to me. Unless I miss understand it is just a special > syntax that only works in the context of passing arguments to a > constructor, method or function, and not a first-class language > element. If we were to go that route I think we would find it highly > limiting.
The JSON-esque syntax was one of the options previously discussed the last time named parameters came up. I am not wedded to it, it was just the most readily-available way to demonstrate named params being opt-in. If we make them not opt-in, then there is no need for a special syntax at all. I was very specifically NOT trying to propose a Javascript-like Object Literal syntax. It's just one option among many for denoting a named parameters call. So, yes, it only works in the context of passing arguments, by design, that's the point.
> 5. In the section you say that "either of the following construction > styles becomes possible" but you do not talk about the option of having > one of more of the first parameters being positional and the rest being > able to be passed by name, which I think would be an ideal use-case > when you want to force certain parameters to always be passed but make > the rest optional.
Incorrect. I specifically say in one of the notes that we could consider it, but it's not necessary and may be more trouble than it's worth. It's more in-the-weeds than I wanted to get at this stage. Specifically: "We can consider mixing positional and named parameters the way Python does, but I don't think that's necessary." Regarding interaction with Delegation (a la Go, which I also agree is a very nice feature and we wants it, precious), I'm not sure. I would have to defer to Nikita for how that would interact with constructor promotion. Between that and annotations we may well want to explore a different syntax than Hack, but the essential concept is the same.
> 2. Going further with constructor promotion, which you join with named > parameters, how are the parameters represented inside the > constructor/method/function? As different variables methods just like > current parameters? Is there no concept of automatic aggregation of > those parameters into some kind of structure that could then be passed > down to other methods and functions?
Yes there is; it's called $this. The whole point of constructor promotion is that it avoids you writing $this->a = $a; $this->b = $b; $this->c = $c; One possible implementation in fact is to simply auto-generate those exact op codes in the source as it's getting parsed. If you want to then add additional logic in the constructor body that would run after those assignments, cool, those still work, and the corresponding properties are already populated for you to use if needed. --Larry Garfield
  109249
March 23, 2020 19:47 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)
Hi Larry,

pon., 23 mar 2020 o 20:04 Larry Garfield <larry@garfieldtech.com>
napisał(a):

> Merging some replies together here... > > On Sun, Mar 22, 2020, at 8:36 PM, Levi Morrison via internals wrote: > > > In short: I believe our biggest potential win is to focus on 3 RFCs: > > > > > > * Constructor Promotion > > I would vote yes on this, assuming the implementation is sane. > > On Mon, Mar 23, 2020, at 12:55 AM, Michał Brzuchalski wrote: > > > That still doesn't resolve issue with lot of boilerplate when you deal > with > > small objects for which public readonly is enough like object-initializer > > could. So I'm not sure about my vote here. It does solve only one narrow > > situation for me. > > The value here is combining constructor promotion with named parameters. > Constructor promotion itself is useful for the class implementer, but > doesn't help the caller. Named parameters helps the caller, but doesn't > really help the class implementer. The combination of both of them > together gives us something similar to the object-initializer syntax as a > net result, but with many other benefits because it's not a one-off syntax. > > So with the two of them together, you get: > > class Point { > public function __construct({public int $x, public int $y}); > } > > Which then allows any of these construction mechanisms: > > $p1 = new Point(5, 7); > $p2 = new Point({x: 5, y: 7}); > $p3 = new Point({y: 7, x: 5}); > > All of which result in an object you can use the same way: > > print $p1->x . ', '. $p1->y; > > I agree it looks a little bit awkward and differs from object-initializers
known from other languages, but let's say it would work somehow for this example. Now make it not 2 but 10-15 properties with real types sometimes quite long so after 3-5 of them you should break the line, then add some default values. Like a real entity which with typed properties doesn't need setters and getters. The example grows but even when breaking a line after each parameter/property still could be somehow readable. Now as we deal with Entity add some annotations or let's go hype, try with new Attributes v2 proposed by Benjamin Eberlei https://wiki.php.net/rfc/attributes_v2#userland_use-casemigrating_doctrine_annotations_from_docblocks_to_attributes 3 for $id and for the rest at least one attribute per property. class Product { public function __construct({ <> <> <> public int $id, < true])>> public string $name, <> public string $description }); } Let's stop on 3 I think it's enough to see it's: 1. unusual to see annotations in method signature declaration 2. not readable anymore. Now if you say it shouldn't be like that and all the properties should be declared as normal properties, then the constructor is not needed to simplify the declaration but still requires a lot of boilerplate on the caller side undoubtedly. Do you still think object-initializer is pointless and useless and can be replaced with named arguments and constructor arguments promotion? Cheers, Michał
  109256
March 23, 2020 20:20 larry@garfieldtech.com ("Larry Garfield")
On Mon, Mar 23, 2020, at 2:47 PM, Michał Brzuchalski wrote:
> Hi Larry,
> > The value here is combining constructor promotion with named parameters. > > Constructor promotion itself is useful for the class implementer, but > > doesn't help the caller. Named parameters helps the caller, but doesn't > > really help the class implementer. The combination of both of them > > together gives us something similar to the object-initializer syntax as a > > net result, but with many other benefits because it's not a one-off syntax. > > > > So with the two of them together, you get: > > > > class Point { > > public function __construct({public int $x, public int $y}); > > } > > > > Which then allows any of these construction mechanisms: > > > > $p1 = new Point(5, 7); > > $p2 = new Point({x: 5, y: 7}); > > $p3 = new Point({y: 7, x: 5}); > > > > All of which result in an object you can use the same way: > > > > print $p1->x . ', '. $p1->y; > > > > > I agree it looks a little bit awkward and differs from object-initializers > known from other languages, > but let's say it would work somehow for this example. Now make it not 2 but > 10-15 properties > with real types sometimes quite long so after 3-5 of them you should break > the line, > then add some default values. > Like a real entity which with typed properties doesn't need setters and > getters. > > The example grows but even when breaking a line after each > parameter/property still could be somehow readable. > > Now as we deal with Entity add some annotations or let's go hype, try > with > new Attributes v2 > proposed by Benjamin Eberlei > https://wiki.php.net/rfc/attributes_v2#userland_use-casemigrating_doctrine_annotations_from_docblocks_to_attributes > 3 for $id and for the rest at least one attribute per property. > > class Product { > public function __construct({ > <> > <> > <> > public int $id, > > < true])>> > public string $name, > > <> > public string $description > }); > } > > Let's stop on 3 I think it's enough to see it's: > 1. unusual to see annotations in method signature declaration > 2. not readable anymore. > > Now if you say it shouldn't be like that and all the properties should be > declared as normal properties, > then the constructor is not needed to simplify the declaration but still > requires a lot of boilerplate on > the caller side undoubtedly. > > Do you still think object-initializer is pointless and useless and can be > replaced with > named arguments and constructor arguments promotion? > > Cheers, > Michał
Yes, I responded to the annotations point in my earlier reply. I hadn't considered those, so we'll likely need to consider alternate syntaxes if we want both annotations and constructor promotion (which I do). However, note that even the (admittedly fugly) Product example you have above, each property name is listed only once, not 4 times, making it still an improvement on the status quo as far as redundancy. However, I still hold that constructor promotion and named parameters, taken together, are strictly superior to a one-off syntax for objects that only supports public properties, as they offer more capabilities and have less potential to be confused with future additions. Eg, object-initalizer syntax vs named parameters on a constructor; which to use when? Why? Why do both exist? They really shouldn't. Named params would be better than object-initalizers all on their own, regardless of whether constructor promotion is included, precisely because they offer more capability for the same syntactic addition. --Larry Garfield
  109260
March 24, 2020 09:21 kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)
Hi Larry,

In my opinion, one of the core assets of PHP is that it contains relatively
few syntactic sugar compared
to some other languages, e.g. C#. Maybe it's just me, but I believe it
makes the code written in PHP
easier to read. And I think this is what we should optimize for. Not for
saving a few lines of code,
but for making the code easier to read and understand.

Now, if we had constructor promotion, we should search for properties both
on the top of the class
and in the constructor. And I agree with Michał, this kind of code can get
out of hand of control very fast.
That said, I don't think that declaring properties in the constructor is a
good idea. It's also because
many people (including myself) tend to write static methods first (I mainly
use them as named constructors),
so we'd either lose track of properties declared in the constructor or have
to force a code style that
puts the constructor to the top. Also, some IDEs (but PHPStorm for sure)
can generate the constructor
very easily from the declared properties.

Speaking about the evaluation of "Write-Once Properties" and "Compound
Property Visibility",
I disagree in some regards. I'll start with the less important one:

> Because the write-once state is preserved across cloning, it makes > Evolution worse.
I think it's quite expected that properties won't be writable after cloning. That would be a very bad design otherwise. That's why I think your real problem is the opposite: that currently the clone operator is not prepared for this change. That's why I missed the "Rust-like cloning" (or the other clone variant that I presented in the "write-once property" thread) as the solution of the "Evolution" problem of "write-once" properties. My other problem with the evaluation of the "Immutability problem" is that it suggests that immutability is only an external concern, and it isn't a thing in the private/protected scope. Why do you think so? Currently (unfortunately) visibility is the only thing that can at some extent (in external scopes) control mutability in PHP. However, if we look at the problem from the type system perspective, visibility has nothing to do with it: we won't have any guarantee that a property is immutable even if we make it private. To be honest, my impression is that most of the problems you list (e.g. verbose constructor, bean problem, or even property accessors) mainly boil down to the verbosity of PHP (or the "visual debt" problem how some people calls it). As I wrote in the first paragraph, I don't think it's a bad thing. For example, if we had "compound property visibility" then we could separate read/write visibility of properties without using getters/setters (I think this is what you also wrote). If we had property accessors then besides the separation of visibility, we could have materalized properties or properties that validate themselves. Probably the syntax would become more concise, but effectively we would make methods from the properties. But I don't understand why is would be a good thing to have two types of methods? How should we decide if we should use normal methods or property accessors? I think the current situation is much better: use getters and/or setters to separate visibility of properties, and perform validation in setters if you need it. And I I still don't think that property accessors would solve the main use-case of "write-once" properties. Cheers, Máté
  109280
March 24, 2020 22:36 d.h.j.takken@freedom.nl (Dik Takken)
On 24-03-2020 10:21, Máté Kocsis wrote:
> Hi Larry, > > In my opinion, one of the core assets of PHP is that it contains relatively > few syntactic sugar compared > to some other languages, e.g. C#. Maybe it's just me, but I believe it > makes the code written in PHP > easier to read. And I think this is what we should optimize for. Not for > saving a few lines of code, > but for making the code easier to read and understand.
It's not just you. :) I fully agree with you here. PHP has a straight, down-to-earth character with very little magic going on. This is what makes the code easy to understand and debug. I just would not use the term 'syntactic sugar' in this context. To me, syntactic sugar has a positive connotation: A nicer way to express the same thing that is easier to read. Magic is making things happen in non-obvious ways that are easily missed when looking at the code. Magic can look really attractive, until something does not work as expected and you fail to see why. Python code tends to have tons of it. The point where sugar ends and magic begins is a matter of taste. To me, constructor promotion tends slightly towards magic. But then, anyone can choose to use the feature or not.
> To be honest, my impression is that most of the problems you list (e.g. > verbose constructor, bean problem, > or even property accessors) mainly boil down to the verbosity of PHP (or > the "visual debt" problem > how some people calls it). As I wrote in the first paragraph, I don't think > it's a bad thing.
Reducing verbosity is not the problem. Introducing magic is. While property accessors are magic, they are a form of magic that I would be willing to accept, for the following reasons. A nice feature of accessors is that they allow swapping a traditional public class property for a property accessor without changing API. Such a feature currently has little value, because public properties are not commonly used because they cannot be marked as read-only yet. Once public class properties can be marked read-only I would be comfortable exposing them directly, without writing any getters and setters for them. The only thing that would still worry me is: What if I need to add some form of access logic later on? Property accessors allow me to do this without introducing a BC break. So yes, property accessors are magic. However, in combination with read-only properties they would allow for dropping tons of getter methods and directly expose properties in stead. They allow this because they are the 'safety net' which makes me comfortable doing it. We get more PHP and less Java. This probably means that I will occasionally have to actually use property accessors at some point and introduce a bit of magic. Then, it still isn't the worst possible magic. Accessors are explicitly declared on the class, an editor could easily show me that accessing a particular property calls a method and show me the code. It's not ideal but it's not that bad either.
> But I don't understand why is would be a good thing to have two types of > methods? How should we decide if we > should use normal methods or property accessors? I think the current
I would prefer to only use accessors to add logic to property access without introducing a BC break. A successor to using __get() and __set(). For access logic that is obviously non-trivial from the start I would probably continue to use regular getter and setter methods.
> I still don't think that property accessors would solve the main use-case > of "write-once" properties.
Indeed. For that purpose I would prefer a keyword for marking a public property as read-only. Regards, Dik Takken
  109222
March 23, 2020 05:55 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)
Hi Larry,

pon., 23 mar 2020, 01:48 użytkownik Larry Garfield <larry@garfieldtech..com>
napisał:

> 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 >
That still doesn't resolve issue with lot of boilerplate when you deal with small objects for which public readonly is enough like object-initializer could. So I'm not sure about my vote here. It does solve only one narrow situation for me. * Named parameters
>
What would be nice for methods and functions. +1 * Compound Property Visibility
>
I didn't get it what benefits over property accessors it could have.
> For details, see the full writeup: > > https://hive.blog/php/@crell/improving-php-s-object-ergonomics > > Thank you for your attention. > > -- > Larry Garfield > larry@garfieldtech.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  109223
March 23, 2020 06:07 mike@newclarity.net (Mike Schinkel)
> On Mar 22, 2020, at 8:47 PM, Larry Garfield <larry@garfieldtech.com> wrote: > https://hive.blog/php/@crell/improving-php-s-object-ergonomics
Hi Larry, That is a really excellent writeup. Thanks from me at least for taking the time to write it up in depth. Looking at your conclusion, my gut feelings tell me your conclusion is about 85% there, but with about 15% that gives me pause unless addressed, which I think is imminently possible. I'm going to do my best to explain what I am envisioning but realize I had not reserved time for this today so I am rushing to complete before my Monday starts in too few hours. Given that I will almost certainly not be as clear in my thoughts had I had time to write and review it so please ask for clarification if something does not make sense. --- 1. Your post mentions validation needed for value objects — a concern I share — but AFAICT your conclusion does not address the issue. 2. It also mentions overlapping concerns and references numerous RFCs, but there were two other relative works not mentioned. One[1] is an RFC and the other[2] a PR on Github. I think they both overlaps with this problem space, with the former addressing validation whereas the latter case potentially conflicts with constructor promotion. 3. And finally, some of the proposed concepts add syntax elements but do not make them first class language elements. --- But before I cover those let me cover what I think you nailed to perfection: 1. The need resolve the verbosity of day-to-day programming with classes on PHP. 2. The distinction between Service and Value objects. 3. The value of immutability. 4. The downside of using arrays to pass properties (which is how many of us do it today.) 5. The benefits of contextual access 6. The limited nature of COPA/and write-once properties. 7. The elegance of property accessor syntax and how it can be applied to create readonly properties 8. The elegance of named parameters with the distinction between BC parameter passing and a newer JSON object-like syntax. 9. Rust-like cloning/Construct from syntax. 10. The problem of exposing parameter names as part of an external API for existing code 11. The problems associated with get and set properties actually running code when not expected by the user. --- However, here is were I think your proposal still needs tightening up. 1. You don't really address the value object vs. service object distinction, except on the periphery. 2. You mention the concerns about exposing parameter names as part of the API but don't address those concerns directly. 3. You mention get/set properties surprisingly running code but do not address those concerns directly. 4. Your concept for a JSON object-like syntax for passing parameter feels incomplete to me. Unless I miss understand it is just a special syntax that only works in the context of passing arguments to a constructor, method or function, and not a first-class language element. If we were to go that route I think we would find it highly limiting. 5. In the section you say that "either of the following construction styles becomes possible" but you do not talk about the option of having one of more of the first parameters being positional and the rest being able to be passed by name, which I think would be an ideal use-case when you want to force certain parameters to always be passed but make the rest optional. --- 1. Let me now address the conflict with Nikita's "decorator" pattern support PR (which I and several others think would be better called delegation.) (As an aside, Go has such a feature and after having used it I find working with PHP's lack of delegation to be extremely painful. Well at least we have Traits. You can see my comment on that PR and my proposal here[3] and [4].) I think that delegation addresses the no-win scenario of and thus is an extremely important addition not to block: - "Should I extend a class and have fragile base classes?" - "Should I use containment and then have a nightmare of boilerplate?", or - "Should I use magic methods and loose performance and native ability use reflection and *_exists() functions?" Unfortunately I think that Constructor Promotion assumes that all properties will be associated with the class at hand, and not with classes that are being delegated to. Yes we could assume they are joined together, and distributed to the various delegated instances, but I believe that could get very complicated very quickly. 2. Going further with constructor promotion, which you join with named parameters, how are the parameters represented inside the constructor/method/function? As different variables methods just like current parameters? Is there no concept of automatic aggregation of those parameters into some kind of structure that could then be passed down to other methods and functions? 3. And — I don't want to bike-shed — but I think the proposed constructor promotion syntax could result in potentially high levels of visual complexity that all must be syntactically correct across many different lines. That has the making of some very fragile code and code that is rather hard to follow, much like when developers write "metadata driven" code where they instantiate an array that contains many other arrays and the entire structure traverses several hundred lines of code or more. ---- One key language addition solves many of the above problems. Imagine that we add a "structs" to PHP. As I envision it: A struct is a value object that has properties but either no methods or limited methods. Structs don't need to be backward compatibility except not to conflict with existing syntax. Structs are as simple as this (public is assumed for properties in my examples, unless otherwise specified): struct Person { string $firstName string $lastName } Structs don't have constructors but do have an initializer syntax so Structs would be created like this: $person = Person{firstName: 'Mike', lastName: 'Schinkel' } This of a struct as a lightweight object with a few non-BC rules (like pass-by-value, more on that below). Struct properties could be accessed just like object properties, with the thin arrow ("->"): echo $person->lastName; Structs could potentially have get/set so as to allow read-only or write only properties: struct Person { // This is read only private string $firstName { public get(); private set(); } // This is write only private string $lastName { private get(); public set(); } } Structs could possibly also support "Materialized Values" assuming those accessors were limited to only accessing other properties (but that might be really hard to implement): struct Person { public string $firstName; public string $lastName; private string $fullName { public get(){ return sprint('%s %s', $this->firstName, $this->lastName ); } } } Structs could also be extended via classes. class Developer extends Person { function work() { // writes code } } Even better classes could delegate to Structs: class Developer { use struct Person; } And we could use aliases class Developer { use struct Person as person; } And we could disambiguate class DevelopmentManager { use class Manager; use class Developer { work as writeCode; } } Further, we could support define named parameters by defining a Struct. Combine that with Construct-from syntax and it rid of the multi-line complexity and mess of the mess of Constructor Promotion: namespace Structs; struct Person { public string $firstName; public string $lastName; } namespace BizObjects; class Person{ use struct Structs\Person; } Better, we could allow sharing of names between a struct and a class (if in the same file) which could associate them: struct Person { public string $firstName; public string $lastName; } class Person{ use struct; } Which could be equivalent to: class Person{ use struct { public string $firstName; public string $lastName; } } Given the above the following function would only accept the object Person: function renderPersonCard( Person $person ) { /// rendering... } This however could access the struct person: function renderPersonCard( Person::struct $person ) { /// rendering... } With the above class/struct Person, you might create like this: $person = new Person(Person{firstName: 'Mike', lastName: 'Schinkel' }); Or the shorthand: $person = new Person({firstName: 'Mike', lastName: 'Schinkel' }); The above needs no explicit constructor, but what if we need to provide one? Note this example automatically initializes firstName and lastName: class Person{ private static $_people = array(); use struct { public string $firstName; public string $lastName; } function __construct(Person::struct) { self::$_people[] = $this; } } Then there is the concern about parameters that are always required. They could be handled like this implicitly: class Person{ private static $_people = array(); use struct { public int $personId; public string $firstName; public string $lastName; } function __construct(int $personId, Person::struct); } Or explicitly: class Person{ use struct { public int $personId; public string $firstName; public string $lastName; } function __construct(int $personId, Person::struct) { $this->personId = $personId; } } We could even move $personId out of the struct and into the class, if we wanted to: class Person{ public int $personId; use struct { public string $firstName; public string $lastName; } function __construct(int $personId, Person::struct) { $this->personId = $personId; } } But what about our development manager? Note that a class would have an automatic Struct which would just be its properties: class DevelopmentManager { use class Manager; use class Developer { work as writeCode; } function __construct(Manager::struct, Developer::struct) { self::$_people[] = $this; } } The above would require instantiation like this: $person = new DevelopmentManager( Manager{firstName: 'Mike', lastName: 'Schinkel' }, Developer{ide:"PhpStorm", languages:["PHP","Go","SQL","etc.]} ); Which could be shortened to: $person = new DevelopmentManager( {firstName: 'Mike', lastName: 'Schinkel' }, {ide:"PhpStorm", languages:["PHP","Go","SQL","etc.]} ); Or with this construct: class DevelopmentManager { use class Manager; use class Developer { work as writeCode; } function __construct(Manager::struct + Developer::struct) { self::$_people[] = $this; } } Could be shortened further to: $person = new DevelopmentManager({ firstName: 'Mike', lastName: 'Schinkel', ide:"PhpStorm", languages:["PHP","Go","SQL","etc."], }); Structs could also support immutability by having them passed to methods and functions by value — like arrays — instead of by reference like objects. In addition, if we embrace annotations we can address validation (note I'm using 'attribute(s)' keyword because <<>> created too much visual noise and annotation is longer IMO): class Person{ use struct { attributes NotEmpty, ProperCase public string $firstName; attributes NotEmpty, ProperCase public string $lastName; attribute ValidEmail public string $email; attributes CanBeEmpty, ValidPhone public string $phone; } } --- Notice how the inclusion if Structs solve so many of the edge cases of the original proposal, and provide significant new capabilities in a very elegant manner? It addresses: 1. Value objects and possibly Materialized values 2. Need for backward compatibility with objects but not with structs 3. Unifying value objects with classes 4. By-value passing supports immutability 5. Delegation is not blocked 6. The "Named parameters" syntax is directly supported because it becomes the syntax to create struct instances. 7. It leverages Construct-from syntax 8. It reduces repeated references without forcing their declarations between contractor/method/function parentheses 9. Supports working with attributes/annotations better than Constructor promotion 10. And it is fully compatible with Get/Set property accessors. So there you have it. I probably missed something and I probably was not clear enough in some area. Please do me the favor and if you have a question about how something will work first try to envision how it could work so you can suggest that when replying. Looking forward to your thoughts. -Mike P.S. Unfortunately with all the demand lately they seem to have run out of flame-retardant suits so I present this with no such protection. --- [1] https://wiki.php.net/rfc/annotations_v2 [2] https://github.com/php/php-src/pull/5168 [3] https://github.com/php/php-src/pull/5168#issuecomment-586688715 [4] https://mikeschinkel.me/2020/adding-delegation-to-php/#summary
  109269
March 24, 2020 11:52 nikita.ppv@gmail.com (Nikita Popov)
On Mon, Mar 23, 2020 at 1:48 AM Larry Garfield <larry@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
  109272
March 24, 2020 14:20 larry@garfieldtech.com ("Larry Garfield")
On Tue, Mar 24, 2020, at 6:52 AM, Nikita Popov wrote:
> On Mon, Mar 23, 2020 at 1:48 AM Larry Garfield <larry@garfieldtech.com>
> 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 wishes were horses, I'd agree. Though both you and Mate mentioned named constructors; I am not sure how that would play into the compacted constructor 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.
I look forward to it! I am quite open to alternate syntaxes that are more amenable to attributes and delegation, as long as the net result is what we're after: Less repetition so making record-like classes is easier.
> 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.
My own feeling here is that making people care about parameter names is not actually that big of a deal. You should really be caring about variable names anyway. Python seems to do fine with named parameters being part of the contract AFAIK. Especially if we could get it in for PHP 8, that's a major anyway, so I would be fine with it. The other options (opt-in or constructor only) are IMO fallbacks in case we're nervous about it, or if the parser ends up being happier with a more explicit syntax. (Gotta keep the parser happy.)
> 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
I agree that Withers are solving an odd problem; however, it's the same approach that PHP itself takes already. Consider DateTimeImmutable: $d = new DateTimeImmutable(); $d2 = $d->setDate(2020, 1, 3) ->setTime(12, 45) ->setTimezone(new DateTimeZone('America/Chicago') ->modify('+1 week'); That's a Wither pattern. The names a a bit wonky for compatibility with DateTime, but that's the exact approach that Wither methods model. From a user perspective it's pretty good. If the answer to that is "well don't do that", then what's the alternative? PHP offers no other syntax for evolvable immutable objects than private properties with Wither methods. Making Wither methods harder makes evolvable immutable objects harder. Unless there's some entirely different approach I am not aware of to achieve the same goal, in which case please share. :-) Asymmetric visibility gives us the same public result as a readonly flag but doesn't break the existing Wither pattern; it means properties are still modifiable internally, but it's way easier to have self-discipline and not muck with a private property by convention than for a public property. It also flows naturally into property accessors, whereas I really don't know how a readonly flag would interact with them. --Larry Garfield
  109277
March 24, 2020 15:11 kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)
> > If the answer to that is "well don't do that", then what's the > alternative? PHP offers no other syntax for evolvable immutable objects > than private properties with Wither methods. Making Wither methods harder > makes evolvable immutable objects harder. Unless there's some entirely > different approach I am not aware of to achieve the same goal, in which > case please share. :-) >
For transparency purposes: the idea I presented during the discussion of "write-once" properties was to make the following syntax (or a similar one) possible in order to make cloning of these properties possible:
> $self = clone $this with {property1: "foo", ...}; It would clone the object and in the same time change the listed properties
(no matter if they have the "write-once" flag). It would also take visibility rules into account, so a private property could only be modified in the private scope. I think this idea would address your concerns, although I haven't received any feedback about it yet, so I'm not sure if it has any gotchas/edge cases that would make it or its implementation infeasible. Máté
  109286
March 25, 2020 10:57 nicolas.grekas+php@gmail.com (Nicolas Grekas)
> > https://hive.blog/php/@crell/improving-php-s-object-ergonomics
Thanks Larry, that's a good way to move forward on these topics. 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?)
I confirm: that'd be super useful to clean the boilerplate.
> large enough that I will often go with a quick and simple ad-hoc array > structure rather than declaring an explicit value object type.
Yes
> 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 don't share this concern with attributes: they mix without any ambiguity, which is what matters. No syntax is perfect, ppl that prefer the current way will still be able to use it.
> 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. >
I'd like to propose something on the topic. I'm adding object literals to the mix because that's another feature of the language that we're missing a lot IMHO. Actually, there is one existing syntax for objects: (object) [...] My proposal is to allow any class in the casting operator: (Foo) [...] By default, all keys of the casted array would map to properties (with an error when no matching property exists in the current visibility scope). We would then allow for a new constructor method, either: public function __create(array $values) or: public static function __create(array $values): static This method would take over the cast operator and decide how to construct an instance of such a class. There is one drawback: accepted keys are not documented. Sure, property declarations can give a big hint. But I think we can solve this issue later: it's not a blocker to still make things work nicely. Also, this issue already exists with all methods that accept an array of options - and we'll find a solution for those - either using docblocks (there are already ways to use them for that) or using attributes (would be the best of course, once we have them.) Note that this __create() method looks a lot like __unserialize(): it's just called at a different place, but the implementations could be essentially the same. 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. >
Máté suggested this syntax and it has my preference over the one you menton Larry: doubling the visibility keyword could be enough to express read+write access: public private $property; <= public read access, private write access 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... >
I think "withers" solve the problem of immutability in a very pragmatic and convenient way. Take e.g. "private": it can be bypassed using closure rebinding or reflection, and this is really useful, e.g. to build "friendship" relations between classes in the same package (like in C++). On the other side, "final" is a real pain when needing to write proxies/decorators. It just blocks extensibility for no technical reasons really. Let me explain: If as a consumer, I DO want to extend a class, nothing will prevent me to do so. There is always the last resort solution, which is patching the too restrictive source class, either using a fork or some code rewriting tool. Either way, what matters is who is in charge of dealing with the issues this might create. In both ways, what matters is that the original author won't be bothered for things that are not its responsibility. "I broke your app because you messed up with that private property on a class I authored?" no my problem. About final, I usually prefer using the "@final" annotation: it expressed exactly what I need to express as the author of the code: "if you extend, you're on your own - but I'm not dictating what you can/can't do either". I think this reasoning applies to my view on immutability :) Cheers, Nicolas
  109292
March 25, 2020 14:24 larry@garfieldtech.com ("Larry Garfield")
On Wed, Mar 25, 2020, at 5:57 AM, Nicolas Grekas wrote:
> > > https://hive.blog/php/@crell/improving-php-s-object-ergonomics
> > 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. > > > > I'd like to propose something on the topic. > I'm adding object literals to the mix because that's another feature of the > language that we're missing a lot IMHO. > Actually, there is one existing syntax for objects: (object) [...] > > My proposal is to allow any class in the casting operator: (Foo) [...] > By default, all keys of the casted array would map to properties (with an > error when no matching property exists in the current visibility scope). We > would then allow for a new constructor method, either: > public function __create(array $values) > or: > public static function __create(array $values): static > > This method would take over the cast operator and decide how to construct > an instance of such a class. > > There is one drawback: accepted keys are not documented. Sure, property > declarations can give a big hint. > > But I think we can solve this issue later: it's not a blocker to still make > things work nicely. Also, this issue already exists with all methods that > accept an array of options - and we'll find a solution for those - either > using docblocks (there are already ways to use them for that) or using > attributes (would be the best of course, once we have them.) > > Note that this __create() method looks a lot like __unserialize(): it's > just called at a different place, but the implementations could be > essentially the same.
Interesting. If that allowed populating private properties than that would be more capable than either of the initializer proposals that have been put forward. However, this alternate deserialization (as you note, it's basically __unserialize by another name) brings up other issues: 1) If it's a large number of properties, the __create method would still need to manually assign them to properties, just like constructors now. It wouldn't benefit from constructor promotion. 2) What's its order of execution with the constructor? Vis, does the constructor run after __create or before? Does __construct get any parameters passed to it? If it doesn't get called, that's yet another way to bypass the constructor and therefore bypass object validation. ("Make invalid states unrepresentable". If the properties don't logically make sense with each other that should be rejected as early as possible; syntactically if we can, via early validation if not.) Named parameters have neither of those issues, as data still only comes in via the constructor so both promotion and validation work fine.
> 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. > > > > Máté suggested this syntax and it has my preference over the one you menton > Larry: doubling the visibility keyword could be enough to express > read+write access: > > public private $property; <= public read access, private write access
In that syntax, you have to remember which one comes first. There's no indication for the casual reader why public private $property; and private public $property; are different. Plus, just looking at it, "wait, it's public and private? WTF? That doesn't even make sense." It also doesn't extend gracefully to property accessors. Whatever accessors do, if they ever get resolved, would conflict with that, and thus we'd have that many more weird combinations of property metadata that are incompatible. The whole point of the syntax I proposed for asymmetric visibility is that it's gracefully extensible, even if a little more verbose. (If we can find a syntax that is less verbose while still gracefully extensible, I am on board with that.) --Larry Garfield
  109298
March 25, 2020 16:20 php@dennis.birkholz.biz (Dennis Birkholz)
Am 25.03.20 um 15:24 schrieb Larry Garfield:
> On Wed, Mar 25, 2020, at 5:57 AM, Nicolas Grekas wrote: >> Máté suggested this syntax and it has my preference over the one you menton >> Larry: doubling the visibility keyword could be enough to express >> read+write access: >> >> public private $property; <= public read access, private write access > > In that syntax, you have to remember which one comes first. There's no indication for the casual reader why > > public private $property; > > and > > private public $property; > > are different. Plus, just looking at it, "wait, it's public and private? WTF? That doesn't even make sense." > > It also doesn't extend gracefully to property accessors. Whatever accessors do, if they ever get resolved, would conflict with that, and thus we'd have that many more weird combinations of property metadata that are incompatible. > > The whole point of the syntax I proposed for asymmetric visibility is that it's gracefully extensible, even if a little more verbose. (If we can find a syntax that is less verbose while still gracefully extensible, I am on board with that.)
What about the following syntax: class X { public read private write $property; } That would play nicely with accessors: class Y { public read getProp private write setProp Type $property; // or this way around to make it clear which is the setter // and which is the property type public getProp read private setProp write Type $property; private function getProp() : ?Type {} private function setProp (Type $newValue) {} } It seems to me this would allow a clear syntax where you can selectively add accessor method for reading or writing or both, you can reuse existing setting methods when refactoring. Only the isset/unset accessors are missing. I am not sure if they are necessary: isset could be equivalent to ($obj->getProp() !== null) and unset to setting null, but I have not thought this through yet. Greets Dennis
  109319
March 26, 2020 02:36 jakob@givoni.dk (Jakob Givoni)
Hi Larry and Nicolas,

On Wed, Mar 25, 2020 at 9:24 AM Larry Garfield <larry@garfieldtech.com> wrote:

> > I'd like to propose something on the topic. > > I'm adding object literals to the mix because that's another feature of the > > language that we're missing a lot IMHO. > > Actually, there is one existing syntax for objects: (object) [...] > > [...] > > 2) What's its order of execution with the constructor? Vis, does the constructor run after __create or before? Does __construct get any parameters passed to it?
That's the interesting question, though there's probably not any sensible answer that works for all use cases. However, if this kind of object casting (object literal notation) was limited to a certain (extendable) internal class (SPL Struct?), we could have just a final public function __construct(array $properties = []) that then delegates the validation to an abstract __validation() method. Would that at least be a useful alternative to constructor promotion?
> In that syntax, you have to remember which one comes first. There's no indication for the casual reader why > > public private $property; > > and > > private public $property;
I'm wondering - are there any use cases where you would have private read and public write? If not, maybe this issue can be simplified by adding (f.ex.) "semiprivate" and "semiprotected" attribute keywords, the idea being that they give readonly access to the anything else. Though I think it would be great to have a nice, gracefully extensible attribute syntax, maybe it's not necessary to fight over that for this particular issue?
> Either way, what matters is who is in charge of dealing with the issues > this might create. In both ways, what matters is that the original author > won't be bothered for things that are not its responsibility. "I broke your > app because you messed up with that private property on a class I > authored?" no my problem. About final, I usually prefer using the "@final" > annotation: it expressed exactly what I need to express as the author of > the code: "if you extend, you're on your own - but I'm not dictating what > you can/can't do either". > > I think this reasoning applies to my view on immutability :)
:-) I can relate to that in general. Though for immutability, I'm not so sure anymore...
  109283
March 25, 2020 09:47 phpmailinglists@gmail.com (Peter Bowyer)
> > For details, see the full writeup: > > https://hive.blog/php/@crell/improving-php-s-object-ergonomics
An excellent writeup, thank you Larry. Peter