Re: [PEPr] Comment on File Formats::MP3_Playlist

PEPr wrote: > >David Costa (http://pear.php.net/user/gurugeek) has commented on the proposal >for File Formats::MP3_Playlist. > >Comment: > >Hello Bertrand! >Thanks for taking some of your valuable time to review my proposal, see my >comments below: >"A driver model for both input and output would lead to a better designed >interface. Otherwise, you are going to have to add new methods to the main >class or subclass it (bOrk)." > >>> The structure is pretty similar. We do have an input in the constructor and an output. I mean "Main Object" uses Object A or Object B for parsing and eventually Object C or Object D for writing. This way, you can switch from sqlite to another DB easily. Some sort of plugin system if you see what I mean :) BTW, why use sqlite at all and not PEAR::DB or even a file ? >"varchart" is not an sql datatype. BTW, sqlite does not need datatypes, that's >why you didn't get an error. > >>> Fixed to Char now, source updated. Sqlite does need at least to differentiate between 2 datatypes: Text and Numeric "SQLite is typeless for the purpose of deciding what data is allowed to be stored in a column. But some notion of type comes into play when sorting and comparing data. For these purposes, a column or an expression can be one of two types: numeric and text.." As far as I know it considers text any type that containts BLOB, CHAR, CLOB, TEXT. Replace CHAR with VARCHAR. VARCHAR contains the word CHAR and therefore you are safe using VARCHAR in sqlite, it will be handled as text. >And why make it a PHP5 only class, I don't see any PHP5 only features ? > >>> Sqlite for instance. True Sqlite works on PHP4 too but with PHP 5.0.0. very close I started (since beta 1) to code every class in PHP 5. That's up to you. But if you use another output object, you are not tied to sqlite.