Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.
In situations where you simply need a data structure to hold values, what is the best structure & why? I find the syntax when reading from a generic object (ie: stdClass) to be cleaner than when reading from an array, ie:
A quick test demonstrates that foreach does in fact work with stdClass.
It would probably be overkill, but you might roll your own "stdClass". Pass an array to the constructor, and put in the magic __set method. But I'm not telling you anything
P.S. I agree, objects are cleaner looking than arrays. Half as many characters, too.
Aside from the fact that foreach() does work with objects as Jonah stated, you can't use any array function on them. So you either implement your own class or you cast them to an array, run the array functions, and then cast back to an object. If you don't need any of the functions, like sort(), array_diff(), etc... then that's fine, but it seems strange to me just to get a more consistent $a->b format. You might like: http://us3.php.net/manual/en/class.arrayobject.php and/or other SPL classes.
mysql_function(): WARNING: This extension is deprecated as of PHP 5.5.0, and will be removed in the future. Instead, the MySQLi or PDO_MySQLextension should be used. See also MySQL: choosing an API guide and related FAQ for more information.
If the purpose behind it is to simply have hash key/value sets, things like sort() would be useless. Most of the array functions would be pretty useless for an object like this:
I would prefer using "data objects" instead of hashes. In general, there is no difference between them. E.g. JSON encoding would produce same results for both.
VladSun wrote:
You can even apply (some?) array_* functions to data objects:
Tried several, and only array_walk worked for me. Still, it's an undocumented behaviour - manual explicitly lists first argument as being of type array.
PHP arrays are the best for internal processing and internal data storage because of the wide variety of utility functions and in case of PHP, speed. However, for public access, I prefer object wrappers, because PHP arrays have one annoying disadvantage: missing/unexisting key displays a warning instead of throwing an exception, and custom handlers that could change this behaviour are not very reliable.
Thanks for the feedback folks. The type of situation I was referring to was when you simply need to move around a bunch of variables. So no access control, or anything beyond simple reading & writing.
Glad to hear others feel an object will work fine.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
pickle wrote:Thanks for the feedback folks. The type of situation I was referring to was when you simply need to move around a bunch of variables. So no access control, or anything beyond simple reading & writing.
Glad to hear others feel an object will work fine.
Yeah, I hardly ever move around 'variables', but rather 'variables & behaviors, encapsulated behind a single object'. If there is no behavior its not an object/class. So why force a square peg into a round hole. I think its funny when people waste half their time implementing countable, and sortable, for no reason when there is absolute no behavior other than counting or sorting its an array you want!
josh wrote:Yeah, I hardly ever move around 'variables', but rather 'variables & behaviors, encapsulated behind a single object'. If there is no behavior its not an object/class. So why force a square peg into a round hole. I think its funny when people waste half their time implementing countable, and sortable, for no reason when there is absolute no behavior other than counting or sorting its an array you want!
+1
I find it rather telling that PHP has added lots of OOP capabilities, SPL classes, etc. etc. yet PHP provided data (POST, GET, SESSION, etc) is provided as an array. AFAIK there is no way to get PHP to provide objects via an ini setting like 'register_gpc_objects' or something similar. Even in 5.3. Maybe it's because the data is better represented/stored as an array?
mysql_function(): WARNING: This extension is deprecated as of PHP 5.5.0, and will be removed in the future. Instead, the MySQLi or PDO_MySQLextension should be used. See also MySQL: choosing an API guide and related FAQ for more information.
Most of the frameworks use request and session objects. For example Zend's session object does namespacing, expires the login after a certain amount of time, etc.. This way session/request can be mocked/stubbed during testing, replaced in different contexts (CLI vs web)
I'm going to be pedantic/semantic (take your pick) here, but they actually aren't arrays. They are dictionaries, because we are afforded the luxury of strings as indices. I'm pretty sure if we had to use 0 indexed arrays we'd all be happy to use a dictionary class in place of our arrays.
Having said that, I'm not a fan of using a string as an identifier. If I'm passing a labelled value to another object, I don't want it to be on the assumption that the receiving/giving class is going to be using the same string, I want it to be explicit. Thus a parameter object (if not a parameter first class)
I'll use an array if I'm just passing an enumerable collection of items, but otherwise I'll do something else to ensure it is explicitly referenced.
Jenk wrote:I'm going to be pedantic/semantic (take your pick) here, but they actually aren't arrays. They are dictionaries, because we are afforded the luxury of strings as indices.
+1
We had a discussion on this topic recently: viewtopic.php?f=1&t=119674
I'm with Jenk onthat hashes are not arrays. They are closer to objects than arrays.
There are 10 types of people in this world, those who understand binary and those who don't