Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28539
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.182.188 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding;
        b=FIuHcyUy7eil41LWU50qjXHIHrTDnB0q9l65tqUnFU1JXrKnmQXt8K7s9YXqPZSz3VvMMuXu2kmqKbLhdCGHj2w15Wt83O4rDAX6Xt8hlUZ5zt5ZAqbeAIQ/gCeIoQBln/QWlTN8XZ8EPOJpek5ei+/qac//COeLLCWQqd5ZjK0=
To: Jacob Santos <dragonwing@dragonu.net>
Cc: internals@lists.php.net
In-Reply-To: <6F.10.09395.26751064@pb1.pair.com>
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>  <6F.10.09395.26751064@pb1.pair.com>
Content-Type: text/plain; charset=utf-8
Date: Wed, 21 Mar 2007 17:52:47 +0100
Message-ID: <1174495967.14132.22.camel@lena>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] google SoC - dbobj
From: thefirstofall@gmail.com (=?ISO-8859-1?Q?Bank=F3_=C1d=E1m?=)

> 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.

Maybe true, it would be easier to create the standard from scratch. But
look at the good side. There's a current API that we can start talking
about. The current outer interface (what matters most for PHP
developers) is very flexible. And if the community can settle at a
standard API, I'm willing to implement it.

Please, everyone, have a look at one of the examples (dbobj.php or
forum.php in the source) and decide if the current API is a good
starting pont.

As for the SoC application, I'll try to write something not too specific
so the specification won't go against the community's future decisions.
I hope google will accept it this way...

Adam

> 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
>