Any developer who has spent a little time working with PHP knows one of the most used compound types - the array. Its uses reach from de-serializat...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
I love XQuery where everything is a list
I actually didn't know you could generate documents with it. Yeah, looks pretty awesome!
Try eXist-db.org
I am going to write language independent framework (based on something like html but for server side) - i hope you can help with it, from my side i can help you with XQuery & XSLT
Maybe I will. I'd be happy to read more about it's goals!
Can't find pm here you can find my telegram by same name
That's right, there's no PM here. But there's PM in Twitter; link in my profile.
No twitter here in russia 🗿
Oh man, I'm really sorry to hear that. Stay strong, and don't lose sight of what is right.
Yep, maybe as part of aggressor country i should kill myself but i have two dogs and one cat so everything not so simple.
Don't do that, please. Dying is easy. And I'm not talking about "немножко потерпеть". But fighting and going forward is the only way. I really hope for the best in Russia, and for the Russian people. Perhaps, it is up to them to bring down this abomination.
Stay strong, buddy! And same to the people of Ukraine!
Heya, @suckup_de! Could you expand on that a little? I'm not saying anywhere that I don't use collections, but also I am not sure exactly how you mean their usage here. You can specify the type for the index and the value, yes. But I am once again unsure how this relates to what I write here.
Heyho, if you want to be sure the "thing" needs to be of a certain type, use typed collections.
They mostly already have or you can simply add e.g. the Iterator interface, and voila. 🙂 No need for falsy phpdocs in the application logic anymore.
Oh, yea, totally. But I thought that you are either agreeing or disagreeing with what I wrote here, while it seems that you are adding a point about collections.
The biggest issue that I have seen among freshers and students is that they are hardwired to imagine arrays as sequential list. Most coaching institutes in India doesn't explain students about the under the hood concepts. All they are taught is that all PHP arrays are associative.
Also, PHP as a language itself, has evolved a lot from 4 -> 5 -> 7. PHP that I code today is not the same that I learned back in college. When I was in college, PHP wasn't an Object-Oriented language. The OO features added in PHP-5 were mostly a syntactic sugar over functional php. This is the reason why all the memes about PHP being dead originate from, people still imagine it as its older incarnation.
PHP Arrays are ordered hashmaps under the hood, thats why it is more powerful than conventional arrays found in Java or C, at the same time it is more frustrating for those who still visualize it as common list type array. But that doesn't mean they are slow.
arraytype might feel like too wide, but it isn't.from the docs
Hi!
Fair points about the evolution, and about outdated thinking. However, I never claimed that arrays are slow; just that expecting or passing an array is probably much more than what one wants, which creates the kind of problems I describe here, and hence this type is too wide.
You are stating that it is not too wide. What would you like to back that up with, given the detailed explanation of my reasoning given in this article? Which, by the way, has nothing to do with what they teach you at school, or with how PHP arrays are implemented under the hood.
When you say
arraytype is wide, I am assuming you are talking about all the features, functions, etc it have on it. If that is what you were going for, then php arrays are not too wide, because it has all the functions that is expected from a map collections. Infact, look at the functions related to maps and collection in any language, Java, C, D-lang, Go-lang etc, they are all similar to whats in php. The only thing that is different, is that those languages have have both sequential list (traditional simple array) and collections (maps) whereas php doesn't have any traditional sequential array, only maps that fulfills both roles. Only reason why it feels too wide, is because of the perception of traditional arrays in other languages.Long ago, when I read the following blogpost, I tried to be cautious around php arrays, But looking back, in past 10 years, there may have been maybe 2 niche scenarios where I even had to think about it. Infact, I have worked on some java projects where people have made complex array-utils library to implement some handy features which are basically available in php for free.
Your example in the Data representation section, is basically a proper, secure, OO way to do that, irrespective of language. That approach is very similar to design pattern used in JavaBeans or kotlin data class, albeit a bit more smaller pieces ( it may be generalization pattern? or specialization pattern? ) .
From what I read, this post covers design pattern, not php arrays.
Just re-read your summary section, you have made amazing points on design patterns, but it had nothing to do with merits and demerits of php arrays. Specifically in your last point about only providing minimal interface under ISP, That is true for all languages. For example, using JavaBean, we don't expose entire java array of a data, we create interface which implements minimum functions needed downstream, abstracting the array ( or collection ) itself. This technique is basically enforced on most OO languages I have worked with.
Oh wow, thank you for such an extensive reply!
I think we're just looking at it differently. I am referring to the
arraytype as an interface, a collection of known common attributes of all arrays. I feel that you may be referring to the implementation.The point I am making is that the interface of the array is comprized of multiple different smaller interfaces, which as you have correctly pointed out would be hidden behind an abstraction in an OO scenario. Depending on
array- i.e. read, write, and enumerate interfaces of it, as they are inseparable from thearraytype - is making too many assumptions that are not useful anywhere.For example, I have nothing against
sumNumbers([1, 1, 2, 3, 5]), because an array is an easy way to create something that passes theiterabletypecheck.What I believe is wrong is requiring an array there. If
arrayvalues would pass theArrayAccesscheck, I would have nothing against declaringfunction getGreeting(ArrayAccess $user): string, and then invokinggetGreeting(['first_name' => 'Santa', 'last_name' => 'Claus']). But unfortunately, it does not work, which IMHO goes a long way to reinforce my point.What do you think?
Another perhaps more pragmatic way of explaining this.
By depending on
arrayin my signature, it's the same ISP issue as with depending onArrayAccess&Countable&iterable- why would you do that? Except that a real concrete array won't pass that typehint in PHP, which is even worse, because it necessitates a userland interface for something so extremely simple.And I'm not saying that there's really never a reason to depend on
ArrayAccess&Countable&iterable. But if you are depending on 3 interfaces by depending onarray, you should know well what your reason is. And that I'd be curious to know it.This point of view makes sense. You are right, while arrays are one of the way to work on data, in practical real world usage, it is safer to limit exposure.
Now this do make sense. PHP arrays does expose the three interfaces. Although like we know, this is by design, a side-effect of emulating an array using ordered maps. Maybe this is why some frameworks prefer to abstract these. Maybe they will rewrite the internals someday, but it would be tough to do that without breaking the internet.
In a talk by Rasmus Lerdorf, he mentioned how he never intended PHP as a language that we know today, that is why all these inconsistencies in internal apis, the language quirks, etc, are all there because he created PHP to be something else. It was after the fact of PHP's popularity, that he decided to rewrite the language internals from the scratch, in a way that it doesn't break internet, yet become a proper backend language.
Now this do make sense. PHP arrays does expose the three interfaces. Although like we know, this is by design, a side-effect of emulating an array using ordered maps. Maybe this is why some frameworks prefer to abstract these. Maybe they will rewrite the internals someday, but it would be tough to do that without breaking the internet.
In a talk by Rasmus Lerdorf, he mentioned how he never intended PHP as a language that we know today, that is why all these inconsistencies in internal apis, the language quirks, etc, are all there because he created PHP to be something else. It was after the fact of PHP's popularity, that he decided to rewrite the language internals from the scratch, in a way that it doesn't break internet, yet become a proper backend language.
Exactly. Because it is just more predictable this way.
I'm glad we have come to an agreement.
Thanks for the amusing conversation :)
Why do you not use a Collection with TKey and TValue? 🤔 I think modern tools will support Generics, so that you can specify your index and your values. And it's a easy replacement for "array".
In PHP, Arrays "are" key-value collection under the hood. It's not an array in traditional sense. Which means that it exposes a lot larger functionality on data set. Therefore it is common practice to use design patterns similar to what the author has demonstrated, to minimize the exposed surface of data to users. This is the reason why Laravel has so many functions, they basically abstract the data behind, providing you individual APIs to manipulate/access the data, making sure its integrity is maintained. A similar approach was used by codeigniter, but they did allow direct access to data, so companies would make internal rules to use only framework functionality, to make sure integrity was maintained.