Page 2 of 2
Posted: Sun Oct 22, 2006 12:59 pm
by Weirdan
Aha, but a class implementing ArrayAccess is not a native Array per se
Aha, but a Registry is not a ServiceLocator per se
Jokes aside, it seems class-based Registry does not provide anything the array can't (including future extensions possibility).
Posted: Sun Oct 22, 2006 1:21 pm
by Maugrim_The_Reaper
A class based Registry offers flexibility... I'm not disagreeing really, but an array is the simplest form of a Registry's behaviour - the simplest form is not always the required future behaviour. I'd always start with the class first under the assumption it would grow in complexity in the future.
I forgot to note Type Hinting as a possible reason to use a class.
Posted: Mon Oct 23, 2006 8:54 am
by Buddha443556
So, why use more complex class-based approach?
By not using an object you lose the benefits of a defined interface, encapsulation and information hiding ... to name just three reasons. Those are pretty important to large scale development with hundreds of developers. I wonder if you can get away with that on the small and medium scale though? Where the lines of communications are simpler and the supervision is tighter.
Posted: Mon Oct 23, 2006 3:31 pm
by Weirdan
By not using an object you lose the benefits of a defined interface...
Arrays don't have a defined interface? Now that's interesting
...encapsulation...
by implementing ArrayAccess in the future you would get the encapsulation (and 'enhanced behaviour') you want
without sacrificing interface simplicity. And to start with you do not create excessive entities just to wrap (or 'glorify', in Maugrim's terms) plain old arrays. Occam's razor in action. I heard agile developers invented a new term for this 600+ years old concept: YAGNI.
information hiding ...
see above.
What I argue is not that class-based Registry in some ways inferior to array. It's that the array interface is most logical to tasks the Registry performs.
Posted: Tue Oct 24, 2006 9:03 am
by Mordred
Interesting arguments, Weirdan, maybe one has to be vigilant for more syntactic sugar wrappings like these.
In my view simplicity indeed pays off - and as far as interface simplicity the array is much more intuitive than an object. A parallel in C++ is the concept of smart pointers - they are behaving just like regular pointers, using the usual native syntax (an example of the same thing gone wrong is the cin and cout-style predefinitions of shift operators - they don't behave like the usual shift)
A possible drawback for some (like me) is that in PHP4 the arrays are "just arrays", but for the majority of cases this would be enough.