Re: Structured data

Philippe Jausions wrote:

How much sense would it make to have in PEAR some base classes for data structures? Think along the line of Structure_Location, or Structure_Phone. This would allow to not reinvent the wheel for packages that use similar complex data types. Vcard and address book packages of course, but also for web services such as mailing (UPS, FedEx, Postal Services) or location services (a la Google Maps and so on...) Even though it would just be a glorified array and would increase package dependencies, it would also allow for better API for packages making use of such Structure_* classes (typing comes to mind) and increase package interoperability. Is it too framework-specific? Should it just be an Interface instead of a class? Any thoughts?

I would be for something along these lines. I would think an interface would be the most useful, but basic implementations might not be a bad idea: class Structure_Phone implements Structure_Phone_Interface { } class Structure_SSN implements Structure_SSN_Interface { } With something like: interface Structure_Phone_Interface {

       protected $_country_code = null;
       protected $_number = null;

       public function __get($key);
       public function __toString();

} interface Structure_Phone_US_Interface extends Structure_Phone_Interface {

       protected $_area_code = null;

} These could be packaged separately and bundled as part of a Structure package. They would also serve as an excellent base for a Validate bundle with packages to handle validation all sorts of structures of data. interface Validate_Interface {

       public function isValid();

} class Validate_Phone implements Validate_Interface { } class Validate_Phone_US extends Validate_Phone { } etc., etc. The Validate objects would be extremely useful for unit-testing as it would easily allow complex assertions without having to write all of the validation yourself or include the bloat in the test package. -Travis