Implementing a memory-efficient arrayAccess class in PHP

I am creating a class that implements the composite pattern; the class is supposed to be able to represent a tree (so let's call it Tree).

In order to use as little memory as possible, when a Tree class instance is passed an a开发者_开发技巧rray, it is kept as an array until the index is required; at which time a new child Tree instance is created and returned

The reasoning for this: My Tree instances pass through many filters and their content might be traversed and modified by many observers, but their content will be requested only once (on the final rendering). Moreover, a certain chunk might not be rendered at all, so it would be wasted memory to create instances of Tree that are not even going to be used.

In other words, if one uses

$class->set($array,$index); //(or $class[$index] = $array)

, the array is stored as normal. But when someone uses

$class->get($index) //(or $class[$index])

, a new instance of Tree will be returned (and cached for subsequent calls).

However, I am left with a dilemma: Do I

1. create a new instance of Tree when someone sets data?
   • Pros: code is easy to write, easy to maintain, easy for someone to pick up and improve upon
   • Cons: memory consumption, even more if we consider a part of the data entered might not be used. Manipulation gets more messy as special methods have to be written for special cases (as opposed to dealing with native arrays).
2. leave it as is, but have people do $class[$index] = array($index2=>$array)?
   • Pros: everything stays stored as an array, so normal array functions work, and memory consumption is minimal.
   • cons: the usage is less "elegant", and possibly more complex.

I know this is not a forum, so I am not asking for opinions, but for the advice of someone having already developed a (potentially heavy) tree structure in PHP and what is the best way (or "accepted way") to go about it.

---

Demo creating the Tree on construct and Demo creating Tree on demand are simple tests you can run for yourself.

The latter creates new node objects only when they're accessed, thus the memory consumption is not that high.

The beauty of object oriented programming, encapsulation and facades is that nobody cares what you do internally, as long as the API does what it's supposed to. Whoever / Whatever is using your TreeNode doesn't need to know how it functions internally. Just go with whatever feels right. Design your APIs right and you can change internals any time.