PEPr: Latest proposals with status Draft

PEPr Proposal [567]: Web Services::Services_Shipping

2008-08-13T22:44:26-05:00

Proposed package: Web Services::Services_Shipping

Proposer: Kristopher Ives

A framework for shipping services that allows sub-packages to provide different shipping carriers, services, and features. This package includes only the framework interfaces. Packages that provide shipping services will have the name "Services_Shipping_Driver_XYZ" where XYZ is some upper-case identifier.

The Services_Shipping_XML package extends the framework to make it easier to implement for XML-based carriers that use HTTPS using the PHP5 domxml and libcurl.

Services_Shipping requires PHP versions 5 or newer.

PEPr Proposal [566]: Database::DB_MY_ACCESS

2008-07-14T23:15:16-05:00

Proposed package: Database::DB_MY_ACCESS

Proposer: Jyot Vakharia

This package is written from scratch, without any base class required. It is created to make the access to database more robust, easy to use and a tracked one. It still requires some work to it, but for now, it has got some functions which can make your development easy by converting mysql return into arrays. This makes the development very easy and fast. I will be putting the class for now, while I am documenting it. Any documentation help for PHP Documentor would be highly appreciated.

Thanks

Jyot Vakharia

PEPr Proposal [561]: PHP::functional

2008-06-23T07:54:44-05:00

Proposed package: PHP::functional

Proposer: Andrew Kovalev

functional will provides PHP users with numerous tools common in functional programming, such as foldl, foldr, flip, as well as mechanisms for partial function application and function composition.

This is will ported from Python functional module.

Look here :http://oakwinter.com/code/functional/

PEPr Proposal [558]: Text::Text_Beautifier

2008-05-17T08:30:29-05:00

Proposed package: Text::Text_Beautifier

Proposer: David Kendal [Wishlist]

Basically, this package will contain a set of functions designed to make text more aesthetically pleasing and better reading. It will contain functions for generating word-numbers from integers, working out where plurals should go, generating the correct rendition of st, nd, rd, th for numbers as well as producing lists with an "and" on the end.

<?php


class Text_Beautifier {


  function english_list($array, $glue=", ", $lastglue=" and ", $oxfordglue=1) {


    if (count($array) == 0) {


      return FALSE;


    } elseif (count($array) == 1) {


      return $array[0];


    }


    $count = count($array)-1;


    $last = $array[$count];


    unset($array[$count]);


    $str = join($glue, $array);


    if ($oxfordcomma) {


      $str .= $glue;


    }


    $str .= "$glue"."$last";


    return $str; }


    


}


?>

This shows what I have got so far - the readable list function.

Interested? I invite your comments...

PEPr Proposal [557]: PHP::Kernel

2008-05-02T11:16:41-05:00

Proposed package: PHP::Kernel

Proposer: Tsvetan Filev

PHP framework for rapid applications development. Automatic environment recognition: mobile devices; SOAP; XML-RPC; RSS

PEPr Proposal [551]: RFC::Lowercase namespace/package names in PEAR2

2008-04-13T21:27:36-05:00

Proposed package: RFC::Lowercase namespace/package names in PEAR2

Proposer: Travis Swicegood

With the introduction of namespaces we have the challenge of determining what part of a fully-qualified package name is the namespace and what is the class. This becomes a larger issue when you try to instantiate what is only a namespace.

To help with this issue, I am proposing we move to lowercase characters to signify what is part of the full name is the namespace/package name, and what part is the object.

Examples:

These examples are written assuming RFC #549 passes:

The Text_Diff package in PEAR becomes pear2::text_diff. The class Text_Diff becomes pear2::text_diff::Diff.

The Text_CAPTCHA package in PEAR becomes pear2::text_captcha. The class Text_CAPTCHA becomes pear2::text_captcha::CAPTCHA.

PEPr Proposal [550]: Web Services::Services_GeoNames

2008-04-10T02:57:03-05:00

Proposed package: Web Services::Services_GeoNames

Proposer: David Jean Louis

PEAR interface to the GeoNames web services.

The GeoNames database contains over 8,000,000 geographical names corresponding to over 6,500,000 unique features. All features are categorized into one out of nine feature classes and further subcategorized into one out of 645 feature codes. Beyond names of places in various languages, data stored include latitude, longitude, elevation, population, administrative subdivision and postal codes. All coordinates use the WGS84 system (World Geodetic System 1984).

Those data are accessible free of charge through a number of Web services and a daily database export. The Web services include direct and reverse geocoding, finding places through postal codes, finding places next to a given place, and finding Wikipedia articles about neighbouring places.

You will find more informations on the GeoNames website.

PEPr Proposal [549]: RFC::Package Naming Conventions

2008-04-06T15:32:23-05:00

Proposed package: RFC::Package Naming Conventions

Proposer: Travis Swicegood

note this is a work in progress that is merely a collection of notes at this point

This RFC calls for a change in the way package names are mapped to namespaces. It will use existing packages within the context of PEAR2 will be used throughout to show how existing code would fix into this.

Using PEAR's Text_Diff class in the Text_Diff package, in PEAR2 the class would become PEAR2::Text_Diff::Diff. Or in PHP code:




namespace PEAR2::Text_Diff;


class Diff


{


    ....

This package/namespace combination is reached via:




namespace Vendor::Package;

PEAR2 is the Vendor, the package name is Text_Diff. Within the current directory structure, this would map to include_path/PEAR2/Text_Diff/Diff.php.

Background:

PEAR packages currently do not enforce a single-directory, single-package rule. This makes it harder contain packages within a version control system through means such as Subversion's svn:externals or Git's submodules.

This proposal is aimed at making the package name map to a specific directory and that each file within that directory is considered part of its package.

Benefits:

Tracking packages within a version control system is easier as most modern vcs delineate externals along directory lines
Keeps existing package names in tact
Allows classes to be properly named by their use instead of forcing names by their location within a directory hierarchy
Helps explicitly show what is a class and what is a namespace (first two elements are always Vendor and Package Name, everything else is the class)

Drawbacks:

Changes existing, 9 year structure
Changes existing behavior of "_"

Examples:

The examples that follow are meant to be illustrative of how an existing package might fit into this new structure. These are not meant as a discussion of the benefits of one particular implement over another, but only so we are discussing familiar code.

MDB2 Example




<?php


namespace PEAR2::MDB2;


class MDB2 {


    ...





namespace PEAR2::MDB2_MySQLDriver {


class Driver {


    ...

The existing MDB2 package presents a unique case with its package and sub-package model. The current PEAR implementation of its drivers requires the naming convention "MDB2_Driver_<SomeDriver>" in order to keep all of the drivers in a central location. With the new autoload capable code, you would check for the existence of a properly named package, the MDB2_MySQLDriver (note that MySQL in this package name modifies the "Driver", and not the other way around).




<?php


// possible snippet for checking for a driver...





$driver_name = $this->getFullyQualifiedDriverName($driver);


if (!class_exists($driver_name, true)) {


    throw new UnknownDriverException($driver);


}





// etc., etc.





function getFullyQualifiedDriverName($driver) {


    if (strpos('::', $driver) === false) {


        $driver = 'PEAR2::MDB2_' . $driver . 'Driver::Driver';


    }


    return $driver;


}

This also allows for the presence of a namespace token ("::") to signify that you want to use your own driver that's not part of the PEAR2's MDB2 distribution.

Text_Diff and Text_CAPTCHA Example:




<?php


// located in include_path/PEAR2/Text_Diff/Diff.php


namespace PEAR2::Text_Diff;


class Diff {




<?php


// located in include_path/PEAR2/Text_CAPTCHA/CAPTCHA.php


namespace PEAR2::Text_CAPTCHA;


class CAPTCHA {

This demonstrates two classes that could very possibly be used in conjunction. In a normal PEAR style installation, these two files would be located in the same directory. The new method would put both of them in their own directories, allowing external developers to track versions independently.

PEPr Proposal [540]: Framework::Trigger

2008-03-09T13:51:22-05:00

Proposed package: Framework::Trigger

Proposer: Wesley Cope

Trigger 1.0 (http://openrosewood.com/files/trigger-1.0.tar.gz) is a small base framework for developing PHP5+ applications. With no complex DB structures (our db abstraction is mysqli with 3 helper functions). Following the standard (and strictly) Model View Controller (MVC) structure, Trigger is the smallest, fast, and most stable frameworks available. Utilizing PEAR setup and installation practices would allow for Trigger to have a central install of system files and make using trigger easier. Also with the plugin system, trigger can utilize PEAR packages when ever someone wants to use them

PEPr Proposal [515]: XML::XML_Feed

2007-11-01T11:52:58-05:00

Proposed package: XML::XML_Feed

Proposer: Michael Jackson

This package provides a base for XML feed generation classes to extend from. Already, two implementations (RSS2 and Atom) are complete. Combined with XML_Feed_Parser, this package will provide complete support for reading/writing all of the most popular types of XML feeds with PHP.