Re: OOP slow -- am I an idiot?

On 10/13/06, Stut <stuttle@gmail.com> wrote:

Ed Lazor wrote: ...Or is it something else entirely; I dunno, maybe UserCollection has a property defined as an array of User class? I think that's what people were saying earlier in the thread as being a "very bad thing" in terms of memory utilization, etc.

I'm honestly having a difficult time thinking of any way *other* than having an array of User objects. In previous projects I've tried the route of (like Richard mentioned early on): class Customers { var $ids = array(); var $names = array(); } But found it very cumbersome and unintuitive when dealing with a single Customer. Moreso I got lost when I didn't know if I were dealing with one or many customers... As soon as I went to a Customer and CustomerCollection approach, I was able to make sense of it all. Even though CustomerCollection usually didn't actually exist, except conceptually as an array of Customer objects within my application code. Like Stut suggested, I too have static fetch functions derived from the base ActiveRecord class that return arrays of objects. Maybe all of my applications have been "simple" enough in that I tended to work on single objects 95% of the time, and therefore creating interfaces for those single objects made sense. I think that's what Ed means by situational? It is occuring to me that perhaps all of my bias is centered around the fact that I always create my models as children of an ActiveRecord class, which is by nature based on *one record* of a table. Is there an ActiveTable class that, if implemented, might completely change everything??? Until then, I'm not convinced: constructing a basic building block such as a Customer, and then an aggregate block such as a collection of Customers, and so on, seems the most stable and scalable approach almost without exception...and perhaps, with that, I'm revealing the extent of my OOP naivety... John W