Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28537
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <6F.10.09395.26751064@pb1.pair.com>
To: internals@lists.php.net
Date: Wed, 21 Mar 2007 11:05:43 -0500
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
References: <1174134488.8667.33.camel@lena> <45FC74A5.6080307@pooteeweet.org>	 <1174231834.12274.110.camel@lena> <45FEBD70.2090000@zend.com>	 <1174330743.9134.2.camel@lena>	 <41721.216.230.84.67.1174341117.squirrel@www.l-i-e.com>	 <1174342387.14657.86.camel@lena>	 <bcb7aa500703200643n5c5cf0d5x2c3794d2906c531f@mail.gmail.com>	 <1174476282.5402.35.camel@lena> <c014a9590703210435t45e99712vb2ffd85d7fe206b4@mail.gmail.com> <460118F8.9050807@pooteeweet.org> <46012A5F.8060302@hristov.com> <460131F9.70108@pooteeweet.org>
In-Reply-To: <460131F9.70108@pooteeweet.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] google SoC - dbobj
From: dragonwing@dragonu.net (Jacob Santos)

Developing the extension like SPL would allow for very quick development and 
maintainability for the extension. It is extremely easy to have interfaces, 
exceptions, and in some cases abstract classes written in C and easily updated 
when changes, if any, are made.

I was able to translate a great portion of one project library to a PHP 
extension over a short time period of three days (of course I had the Extending 
PHP book, PDO, and SPL as references... and luckily I didn't need to work with 
any of the C Standard Library).

The way the current project is handled is extremely good. It shouldn't be 
difficult to isolate where the changes need to be made and make them.

As for maintainability, if there are enough programmers, then it shouldn't be a 
hassle to maintain the extension. There are quite a number of features that 
should be implemented in C, even if they are extremely difficult, because it 
would take too long to process in PHP.

I think the ORM C PHP extension will be quicker than anything in PHP. It doesn't 
have to handle everything, just the most common ORM features and allow 
extending. Just need to decide what features that is and what features the 
project already has.

I do think it would be easier to come up with a standard for the project, if 
perhaps Banko didn't spend a whole year and a half on it. I do hope that the 
mailing list sorts out which features should be in the PHP extension to allow 
for interoperability between the ORM PHP libraries. It would probably take 
another year, but it would be nice if it was bundled in a later version of PHP 
5.x and PHP 6.

Jacob Santos

Lukas Kahwe Smith wrote:
> Andrey Hristov wrote:
>>  Hi,
>> Lukas Kahwe Smith wrote:
>>> Robin Ericsson wrote:
>>>> On 3/21/07, Bankó Ádám <thefirstofall@gmail.com> wrote:
>>>>> The project is existing, I'm doing it for about a year and a half, and
>>>>> SoC is way I can spend more time on it in the summer.
>>>> If there is someone willing to something, and someone else is paying
>>>> for it, let him do it. Why should it bother whether it's C or PHP? The
>>>> community will benefit from it either way.
>>> Its a question of maintainability. Stuff like reverse engineering
>>> schema's from a database is simply not sensible to be done by C code. It
>>> requires a low barrier to entry, the ability to quickly fix things if
>>> you encounter a newer or very old obscure RDBMS version etc.
>>
>> Then make a mix of PHP and C code. C call call PHP userland, so it
>> shouldn't be a problem. And as I see it, it is always good to have
>> reference implementation in PHP and port it to C. I think Marcus did it
>> while implementing SPL.
> 
> Yes .. so for the proposal .. step 1) would be defining interfaces and 
> abstract classes to represent things. this could go into C
> 
> regards,
> Lukas