Re: Virtual Filesystem

Ok, had a good long sleep on this one :) - eg. hungover.... These are some of the thoughts - a combined API would be large, and messy - a combined API would be confusing to document and understand. - having two codebases doing the same/or similar things is a waste.. So... The conclusion i had was: System_VFS (or Horde_VFS_Object) would be the base/factory class for the Object Based API. For existing VFS drivers (eg. in Horde_VFS) where possible, the VFS_Object drivers should just static call the Horde_VFS drivers. eg. class Horde_VFS_Object_file extends Horde_VFS_Object { var $_filename; // full path to file... factory($filename) {

       if (!file_exists($filename)) {
               return PEAR::Error('File or Folder does not exist");
       }
       if (isdir($filename)) {
               $ret = new Horde_VFS_Object_file_folder;
               $ret->_filename = $filename;
               return $ret;
        }
        $this->_filename = $filename;
        return $this;

} function write($data) {

       Horde_VFS_file::write($this->getPath(),$data);

} function copyTo($vfsdir,$newname=NULL) {

       if ($vfsdir->getType() != 'file:folder') {
           return $this->raiseError('Can not copy no File to Folder of type ".$vfsdir->getType());
       }
      if  ($newname ===NULL) {
            $newname = $this->basename();
      }
      Horde_VFS_file::copy($this->dirname(),$this->basename(),$vfs->getPath(),$newname);
    }

...... In principle, the 'guts of the drivers' should remain in one place - eg. if it is mostly implemented in Horde_VFS, any updates should be done to that.. If a new driver is written for the object one, then the Horde_VFS, could provide a wrapper to it in a similar way... (this does, end up with circular dependencies, .... can the pear installer deal with that?) If you got this far, (and agree with the stuff above :), the only question remaining is if it should go in Horde or PEAR's CVS, ... I would say Hordes, as if the issue arises that we do have circular dependancies it will be a pain to read the code, if they are not in the same place.... Regards Alan Jon Wood wrote:

Ok, thanks for the opinions on this (I hadn't expected asking about a VFS class to generate such discussion :P). Firstly, I know that there is nothing that proves that object based return values are "better" than array ones, it's just my preference. I like the idea of having the functions detect if they've been passed an object or an array, since it keeps the namespace clean, and also means that things are less likely to break, and if it is possible to do this without causing a fork, I'm all for it :) Jon ----- Original Message ----- From: "Mika Tuupola" <tuupola@appelsiini.net> To: "Chuck Hagenbuch" <chuck@horde.org> Cc: <pear-dev@lists.php.net> Sent: Thursday, September 26, 2002 7:28 PM Subject: Re: [PEAR-DEV] Virtual Filesystem

On Thu, 26 Sep 2002, Chuck Hagenbuch wrote:

There are two options here. One is to have methods like createFolder()

be

smart enough to call different internal functions based on their

arguments

(ie, if I get passed an object, do this, otherwise, do that). The other

is

to just suck it up and have slightly different function names - createFolderObject(), etc.

Personally I like the first option better. Long method names are quite awkward and having different method names just clutter the API. --

Mika Tuupola                      http://www.appelsiini.net/~tuupola/

-- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php