[KLUG Programming] questions on picking data types

[Adam Tauno WIlliams]

> And ditto for the output.  Write one function to format your
> database's raw data into the format you need for output.  You only
> need to write it once, that's how subroutines work.  :)  I don't
> know if making it object-oriented would be right for your program,
> but it definitely should be modular.

Yep, for instance, we have a PHP phonenumber class that looks like -

class phonenumber extends baseclass {
   var $number;

   function phonenumber($number) {
     baseclass::baseclass();
     $this->number = trim($number);
    }

   function isvalid() {
    }

   function get_as_classic() {
     return sprintf("(%s)%s-%s",
       $this->get_area_code(),
       $this->get_exchange(),
       $this->get_last_four());
    }
 
   function get_as_dotted() {
     return sprintf("%s.%s.%s",
       $this->get_area_code(),
       $this->get_exchange(),
       $this->get_last_four());
    }

   function get_as_dashed() {
     return sprintf("%s-%s-%s",
       $this->get_area_code(),
       $this->get_exchange(),
       $this->get_last_four());
    }

   function get_as_number() {
     return $this->number;
    }

....

 - this is a good idea with anything resembling a complex data type.

> In any case, where your data in your DB needs now, or may need in
> future, any kind of massaging either on input or output, it's not a
> bad idea to write that subroutine anyway.  If SSNs do go to 10
> digits and the standard format becomes ######-####, you will want to
> change that in one place, not a hundred.

Absolutely.

> Proper conceptual separation of code and data will avoid a _lot_ of
> headaches in the future.

And the dreaded 'complete-rewrite' phase that many many Open Source
projects have gone through (and many not emerged on the other end). 
Code in small functional pieces;  always ask 

1. Is there some way I can solve this problem in a more generic way?
2. Is any other application or operation going to need this or very
similair functionality?
3. Can I solve this problem at a lower level/layer?
4. How might this change in the future?  What neighboring elements will
that change effect or break?