PEAR OO style: associative array parameter vs. unencapsulated cla ss

Hello, I'm a newbie to PEAR and not so experienced in PHP either. I ask this question here because a) I am developing a package which may conceivably be suitable for PEAR someday and b) I respect the careful attention to architecture and style by PEAR developers. The question: is it reasonable PHP programming style to pass a set of parameters or options to a method as a class instance rather than an associative array instance, even when this means the class is not encapsulated (i.e. doesn't use "getter" methods)? I ask because I observe that passing options arrays as parameters seems to be a common PHP idiom. This works around the lack of true overloading as well as the need to pass parameters 1..(N-1) in case one wishes to provide optional parameter N. Some PEAR packages such as Cache_Lite use this idiom. I thought to do something similar but I have a need for default values other than "null", so a routine to set these default parameter values would be helpful. But I realized that in PHP associative arrays are almost equivalent to objects, and thus I could define a class that in effect models an associative array but also has a constructor. A side benefit of this is that the supported parameters and default values are precisely communicated in the class definition, rather than just being a comment. For example: class RetrievalOptions { // usage: create instance, then customize class // variables that require non-default values var $creation_timestamp; var $author; ... function RetrievalOptions() { $creation_timestamp = time(); $author = ""; ... } } Although such an class doesn't look much like a typical Java or C++ class, these languages don't have PHP's convenient and flexible near-equivalence of associative arrays and objects. Of course I could define "get" and "set" methods but for a construct that's merely a package for passing options or parameters that seems a bit heavyweight. Also, of course I could simply use "null" as a trigger to use the special default values but then these default values would be buried in various places in my code and testing array_key_exists deep in loops etc. may be less convenient. Someone customizing an instance of the above could even choose not to treat it as an object, but rather to use the $myParams["author"] array syntax. And, similarly such an object could be extended by subclassing (extends...) or simply by defining new key-value pairs. I was a bit suprised but pleased to find that all the above work fine with PHP objects. Of course another idiom is to have generic "getProp/setProp" rather than per-instance-variable getter methods, but a totally generic "getProp" seems a bit gratuitious in this situation - since basically the object itself is already an associative array and directly supports the assoc. array accessor syntax. So, while such a "naked instance variable class" would in most cases be considered appalling C++/Java style, it seems like it might be OK PHP style, and maybe a good use of PHP "pseudo-objects" (again, in "lightweight" situations like configuration parameter passing when encapsulation through individual "getter" methods would be overkill). Do people have opinions or precedents on this? Thanks in advance. Bill McCoy bill.mccoy@pictureiq.com