Re: Package Proposal - DateRange and Range - Range Category Needed.

>I don't think a category "Range" would make much sense, however, I think >"Abstract Types" might make sense. The implementations like Date_Range >should go under the type of their implementation (Number_Range under >Numbers, Text_Range for alphabetizing under Text, etc.) Alright, that doesn't sound too bad, but let me ask you this: Are category names supposed to represent related functionality or related types? If it's functionality, then your scheme sounds fine, but if it's types, then Range needs its own category, along with all of the sub-types such as Range_Text, or Range_Date. From an OO perspective, I believe that the categories should represent types (and they do in PEAR). For instance, take a look at the Log category; sub-classes of log end up in Log, not in the Log's implementation type category. For example, Log_sql is in Log, not in DB. Log_file goes in Log, not File. This is 100% correct. Log_sql is after all, a Log. Similarly, Range_Date should go into Range, not Date. (More examples of this can be found in PEAR such as `Auth') Additionally, I can see that Range should probably have a factory method much like Log's. Something like Range::getRange("date", $params); This frees client classes from knowing which specific class was instantiated which improves flexibility and reusability. Hence, all Ranges are treated as Ranges, not as the specific types of the sub-classes. `Program to an interface, not an implementation' Please consider a Range category. I really like the idea of implementing various Number, Text, and Date Range classes. They would fit very nicely into a Range category. For consistency, this would be very similar to other PEAR categories like Log as I have mentioned. Also, if the classes went somewhere other than a Range directory, where would Range go? Whatever, the case, Range should not be discarded, Range enforces a consistent API. Consistent APIs make life easier. Truly, Range is a valid, abstract type of object, which then can be extended to more specific "Range" objects. If PHP had an Object object, Range would extend from Object. As such, that makes Range a top level type, in PEAR or anywhere else for that matter. Thanks, Matt Friedman. Greg Beaver <greg@chiaraquart To: MFriedman@symcor.com et.net> cc: pear-dev@lists.php.net Subject: Re: [PEAR-DEV] Package Proposal - DateRange and Range 18/08/2003 09:22 PM MFriedman@symcor.com wrote: > I'm inclined to think of Ranges as entities and as such their own "type". > While DateRange provides functionality related to Dates, a DateRange is not > a Date, it is a Range. Much the same, if you think of an IntegerRange, you > can't really call that an integer, it's also a Range. With regards to > Validate, while I see that Range has some validation features, it also has > features totally unrelated to Validation (like merge()). As such, I don't > see Range classes in the Validate category. The methods in Range apply to > Ranges and as such I think this makes a case for having a Range category in I don't think a category "Range" would make much sense, however, I think "Abstract Types" might make sense. The implementations like Date_Range should go under the type of their implementation (Number_Range under Numbers, Text_Range for alphabetizing under Text, etc.) I need more time to decide on the package before I can give a +1 or -1 Thanks, Greg -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php