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
