Op zondag 2 juli 2006 21:47, schreef Dries Buytaert:
I don't see the point. Let's just continue using what makes most sense in each of the individual contexts.
We can achieve a lot more consistancy (and thus a lot less code) if we settle for a good guildeline. I certainly do not agree that we should choose only one. Arrays and objects both make sense in lots of cases. We shouldn't try to settle for one, but use the programming language we have in a proper way. PHP has them both, for good reasons, why should we abuse the language, or not allow certain parts of a language to be used? Which does not mean we should leave stuff as it is, but instead we could settle for a guideline. Look at: 1) http://api.lullabot.com/api/HEAD/function/user_save 2) http://api.lullabot.com/api/HEAD/function/taxonomy_save_term 3) http://api.lullabot.com/api/HEAD/function/node_save All three *should* do the same. Yet 1) uses an object *and* arrays, 2) uses only arrays, and three uses only objects. The guideline I proposed several times is VERY simple. And it is the way PHP meant it to be: «use objects for structured items» «use arrays for lists of similar items» Yet everytime the Arrayfetishists (sorry) Shoot that down with theoretically (!) reasonings like "but arrays and objects are under-the-PHP-Hood handled the same", or "one performs better then another one". In the above examples, ALL foo_save and foo_load functions return objects. If you have a lot of such objects (a list of nodes, a group of users) you can put them in arrays. Keyed arrays if you wish. Bèr