pon., 18 lis 2019 o 09:39 Peter Bowyer <phpmailingli...@gmail.com> napisał(a):
> On Sun, 17 Nov 2019 at 23:44, Ben Ramsey <b...@benramsey.com> wrote: > > > > > > On Nov 17, 2019, at 17:28, Mike Schinkel <m...@newclarity.net> wrote: > > > > > > If we are going to open up arrays for enhancement in PHP 8 I would ask > > that we seriously consider addressing the various differences between a > > built-in array and an instance of ArrayObject and/or the related > associated > > interfaces such that the objects can be used interchangeably with a > > built-in array > > > > I completely agree. I would love to see anything implementing ArrayAccess > > able to be used in any of the array functions. > > > > This might be a way-out-in-left-field concept, but if we went down this > > path, perhaps a PHP array could become an object internally (i.e., > > ArrayObject) without changing the way it works in existing code? Then, > > if/when generics are introduced, a PHP array would already be a class to > > which a generic type parameter could be applied. > > > I agree with Mike & Ben. Another voice in support of this. > IMO there is a little catch, at least one. Currently, arrays all together with rest of scalar types are value-types which means when they're passed on (unless passed by a reference) their copies are modified but not the original one. That's cause object's in PHP are reference types, when passed they're always passed by reference. Thus making a general ArrayObject class even internally for now should follow value-types semantics. How do you want to reconcile that? Another thing is when shaping an OO API on general array class -> ArrayObject all of the existing array_xxx functions IMO should be deprecated and that's not likely gonna happen. If you ask me why I think like that, well if ArrayObject is going to be automatically served from all arrays keeping array_xxx functions makes no longer a sense, the only thing they could do from that point is only calling an ArrayObject method, which is different from what they do now they return a new value-type a new array with filtered, mapped key-value array elements, when working with objects you expect them to mutate themself if they're mutable or return a brand new instance when they're immutable. Going further if ArrayObject is gonna have for eg. map() method it should return a new instance of self with different key-value pairs collection - this means ArrayObject has to know how to create a new self. This is easy for built-in class but when you go to polymorphism and would like to extend it in MyFooArray you need to implement map method as well cause maybe there is an additional initialization needed besides of key-value pairs only, for eg. additional constructor argument. If that happens for internal array_xxx functions it would be hard to guess how to create a new instance, they'd become a thin wrapper of calling ArrayObject like methods, nothing more. TBH, in general, I think I wouldn't mess up anything. iterable is a pseudo type cause there were reasons for that. iterable accepts arrays, objects implementing iterator or generator. iterable doesn't mean all that accepts is countable (look at generators). speaking of arrayable probably you're thinking of counting it too, but then it would require to behave like an intersection of types arrayable = iterable&countable - going further it would not accept generators anymore - concluding people would still use iterable and not arrayable for traversing using foreach etc. Just my 50cents. Cheers, Michał Brzuchalski
