Hi, > 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.
COPA won't make me use objects instead of arrays (in legacy code). The problem is writing a ton of classes for all array ever used, in a legacy file structure that comes with more maintenance than you'd like. What would make me use objects would probably be run-time interfaces via a return contract in combination with anonymous classes. > > 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. > I don't remember when the last time was that I used public properties, even for the simplest data objects. Constructors provide all the features I need at this point, and I'm much more interested in making constructors have less boilerplate than their initialization. I can imagine COPA being more attractive once (public) read only properties are a thing, though even then I'd much rather use a constructor as it will let me find usages and add/swap arguments easily. Finding COPA usages of a class will be a lot harder compared to constructors. Regards, Lynn
