Re: Net_FTP design issues

Hi, Tobias,

Now we're hanging at the decision of implementing the new backend in an OO or procedural manner. On the one hand I would preffer OO style, since all in PEAR is OO. On the other hand, if native FTP is not available one can simple include the code (if it's procedural) and will have the functions available with the same API. Forethat I'd preffer to have it procedural.

I would favor the OO approach, but that's just me. I'm afraid I don't understand the procedural argument; you could, for example, give the OO version static methods that can be called like plain functions (Net_FTP::connect() and so on). Then you have the best of both worlds.

The procedural way would have another difficulty to ship around: Storage of the config stuff and Co., which would have been stored in the object in an OO way. I would suggest to store all of that in a global array (e.g. $_NET_FTP), which should not affect most of the scripts it would be used in.

With the static OO approach you can create a static singleton to encapsulate the configs away from the global namespace. Just ideas, hope you find a way to do it that satisfies you. :-) -- Paul M. Jones Savant: the simple alternative to Smarty for PHP. http://phpsavant.com/ DB_Table: build RDBMS tables and XHTML forms in one PHP class. http://wiki.ciaweb.net/yawiki/index.php?area=DB_Table Yawiki: your collaborative online documentation system. http://yawiki.com/ Yawp: a single-file foundation for PHP applications. http://phpyawp.com/