I definitely agree that this would be a cool thing to have. Today PEAR
packages do all of this with PHP code, a more tightly integrated package
concept would be very nice. Comments below.
Stanislav Malyshev wrote:
>
> Below is the proposal for PHP packaging extension. The intentions is for
> PHP to have the package system kind of like what Perl and other languanges
> have. The comments and suggestions are most welcome, as usual. Especially
> the experience with packaging system from other languages.
>
> ===============
>
> Name: Package Extensions Draft
> Version: 1.0
> Author: Stanisval Malyshev <[EMAIL PROTECTED]>
>
> Goal:
> ====
> Create a system that will allow to create and conveniently handle PHP code "bundles",
> containing one or more PHP code files bound by the common function.
>
> Requirements:
> ============
> The system should:
> * allow convenient loading of the whole package with the single statement
> * allow convenient checking if the package is loaded
> * allow the user to conveniently pack the package and to describe
> relationships between the packages
> * this is not meant to replace include() and include_once() but to
> add functionality that will allow more systematic view on the PHP code
> tree
> * the system should sit well with future namespace implementation,
> allowing packages to use the benefits of the namespaces
>
> The system is meant to be implemented as a PHP extension.
> On the best of my knowledge, it can be implemented without interfering
> with any existing code and without needing any code modification in
> any other parts of PHP/Zend.
>
> Proposed functions:
> ===================
> package_load("Name")
> --------------------
> Loads the package with name "Name". The loading is done in the global
> scope (as opposed to include()). Returns true on success.
> If the package with this name was loaded, it just returns true, while
> doing nothing.
> If the package cannot be found, it returns error.
> TBD: fatal error or not?
Since it just returns if the package is already loaded, I think
package_use() or use_package() would be better names for this one. To
me, "load" is unconditional.
> package_is_loaded("Name")
> -------------------------
> Returns true if the package is loaded, false otherwise.
>
> package_set_path("path")
> ------------------------
> Sets the package path for looking for packages. The default is the
> include path.
Yes! This function could be a real problem-solver for those with
less-than-helpful ISPs.
> Technology:
> ==========
>
> Package is located and loaded in the following way:
>
> 1. First, the package location name is determined. If the name does not contain
> :: signs, the package location name is the package name. If the package name
> contains ::, each :: component is a subdirectory, i.e. Foo::Bar::Baz
> produces the location name of Foo/Bar/Baz (just like in Perl).
>
> 2. Package location name is prepended with each directory in the
> package path. The '.pdef' extension is added to the path. If a file
> with such name exists, this is a package definition file, which is
> parsed according to 3. If not, the '.php' extension is added to the
> above path. If a file with such name exists, it is considered to be
> the main file of the package and is included with global scope. This
> file should require_once the rest of the files.
>
> 3. The package definition file has format like the following:
>
> Package: Foo::Bar
> Version: 3.14.15
> Requires: PEAR
> Requires: DB::MySQL
> Files:
> boobar.php
> boo.inc
> classes/class.A.inc
> classes/class.B.inc
>
> Package: line defines the name of the package, should be the same as
> is required (as a sanity control measure).
> Version: is not used in the meantime.
> Requires: line defines that this package depends on other
> package, which should be loaded before this package is loaded. This
> line can be repeated a number of times.
> Files: line marks the start of the file list. The next lines of the
> file, until the end, will be package filenames, one per line. The
> pacthes are relative to the package directory. The files are included
> (just like include()) in the global context and executed, one by
> one. It is not recommended to put any global-scope code but definitions and
> variable definitions into these files.
I think packages should be able to contain both PHP code files and
extension libraries. This would save coders a lot of hassle, and would
be a great feature to have when extensions start moving from php4 to
pear/PECL.
It would be interesting to compare the performance of an XML-based
package definition file and a plain-text one. If the overhead is
acceptable I think we should go with PEAR's package XML format. If the
overhead is too big I think your format is fine.
My suggestion is putting this thing in php4/ext/pear. I want to move
some other code there too, but this would be a good start.
- Stig
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
