NYCPHP Meetup

[Eddie Drapkin]

On Wed, Jan 20, 2010 at 1:42 PM, Michael B Allen <ioplex at gmail.com> wrote:
>
> Unless you need polymorphic behavior where extending a type so that it
> inherits the behavior of another is clearly better, it is very likely
> that you can achieve the same objective more efficiently without using
> objects at all. This is particularly true in PHP because of the array
> type. The array type in PHP is a builtin type and a generic ordered
> but hashed container. So if you just need a context to maintain some
> state with only one reference - an array is a good option.


An array and an object are almost identical in PHP.  Other than
syntactically, as far as resource usage, there's no difference
between:
$a->foo = $bar; //well, you get an E_STRICT here, but you can $a = new
stdClass() to prevent that.
$a['foo'] = $bar;

Internally, PHP objects are hashes as well, so there's no really good
argument to using arrays over objects.

As far as your other argument, the primary advantage to OOP is modular
state tracking.  When you have a lot of procedural code, you either
wind up emulating OOP state tracking (C structs that keep track of
themselves, for example, or huge PHP arrays) or having a big pile of
spaghetti.  And as much as I love spaghetti, I'd rather have it for
dinner than in my source code.  That's not to say that you can't have
global state tracking and do it right, but it's certainly more
difficult and IMO completely unnecessary.