Hi Larry! I have a lot of respect for the vision you're working on. Great advances sometimes come out of great visions. But let's not forget that so far it's only a vision and not all visions come to fruition. We don't know - at the moment it's anybody's guess.
At this point I hardly expect you to change your mind, and it's not that you don't have all the right in the world to an opinion, but it seems to me sometimes it's easy to confuse opinion with fact. Hence, for the sake of my own sanity I will reply to some of your comments. If you feel we're going around in circles, feel free to ignore my replies. For sure, no need to double down on our disagreements. On Sun, Mar 29, 2020 at 4:59 PM Larry Garfield <la...@garfieldtech.com> wrote: > > I went into this in my earlier Object Ergonomics post, but in short, it's > quite possible for a solution to be *too* narrow. > It becomes useful in too small a subset of cases to justify its added > conceptual weight. And what exactly is the added conceptual weight of COPA? As I've stated time and time again, COPA doesn't introduce any new concepts or complexities. If you disagree with that, I'd really like to hear exactly what those new concepts or complexities amount to in your eyes. > (and contrary to the view of some, "if you don't like it don't use it" is > just not a thing when you're working in OSS, > because someone is going to use it and you'll inherit that code). Yeah, God forbid such madness! :-D > A narrow solution can also inadvertently serve to make something too easy > that should be done rarely. > [...] > Or it would nudge users toward making more properties public so that they can > use the shorter COPA, > but in the absence of a readonly keyword, asymmetric visibility, property > accessor, or something along those > lines that is a net loss as it means more properties become public when they > really shouldn't be. Hmmm, record-like data structures (structs?) - devils work in disguise, for sure... :-D If I were being arrogant I'd say that maybe allowing a trailing comma in parameter lists will nudge users towards making methods take more parameters than they should. But I think it's prudent to be modest in such judgements. > In this case, the problem with COPA as proposed is that it only works for > public properties that are assigned literally. That is, in my experience, a > very rare case. You see, here's the funny thing: It's rare because it's a hassle! *MY* experience (I do have some 20 years' worth of such...) is that people tend to use associative arrays instead for data records and the like. COPA aims to change that. And it's not true that the values have to be assigned literally - the assignment can invoke a magic method which can validate and modify a value and store it privately. I'm not saying that is good or bad, just that it's possible and that fact should not be misrepresented. > Most objects want and need to have private or protected properties for a > large variety of reasons, which would make COPA useless. Ooops, careful with such an overstatement, buddy! I don't want to enter into this debate here, just point out that this generalisation is overreaching. Again, some modesty would suit the debate better. Truth before emotions also. > IMO, the combination of constructor promotion and named parameters would have > a much better ROI than a dedicated syntax, > it would not suffer from the public properties problem, it would still allow > for constructor parameters that are not a 1:1 map to properties, > but it would still serve to greatly reduce the amount of typing needed. That > is, that approach offers more functionality for roughly the > same or less additional syntax. The proposed syntaxes for those features are much more complex than COPA's - I hope I'm not misrepresenting it when I say that it currently involves 2 new ways to write a constructor, moving declaration of properties inside a method signature and a whole new annotation/attribute paradigm to try to make sense of it all. And we're nowhere near consensus on any of it. The revived constructor promotion syntax cannot replace COPA without named parameters - and named parameters has not made any significant progress since 2013, unfortunately. I would love to see some form of named parameters, but I'm not holding my breath for it. > In short, the cost-benefit calculation says this is useful in too narrow a > case, and has the potential to encourage bad design in the name of typing > less. > Other alternatives address that problem space better. To list the facts: - Is COPA narrow? Yes - Is COPA useless? No - Will COPA encourage bad design and be overused? Opinion! - Will COPA encourage struct-like objects over anonymous array? Yes - Will COPA pollute the symbol/syntax space? Very little - Does COPA have any implications for future language evolution? None that have been shown so far - Is COPA trivial to implement? Yes Larry, keep up the great work with the Object Ergonomics. I'll follow it closely and contribute when I can. I will move forward with the vote soon. Based on the latest feedback I'd be surprised if it got even a single yes-vote, but I want to have this experience under my belt as well. I respect the vote. I will learn from it in any case. I only wish the vote isn't skewed by opinionated misrepresentation of COPA. Thanks for reading and code responsibly! Jakob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
