Just in case anyone lost track... it seems the consensus is to allow the
optional parameter syntax for class hints. The Nullable class hint doesn't
seem to be well supported among the purists so the optional param syntax,
while not optimal, is better than leaving it as it is now. One can always
rea
On Tue, 26 Oct 2004 09:03:04 +0800, Alan Knowles <[EMAIL PROTECTED]> wrote:
> A few suggestions..
> --
> Fetching into objects:
> This really needs to be sorted out early on, and kludging support for
> something that perhaps should be the default behavour is looking very mes
A few suggestions..
--
Fetching into objects:
This really needs to be sorted out early on, and kludging support for
something that perhaps should be the default behavour is looking very messy:
a) if you want to fetch into a specific class, make that class extend PDO...
clas
Hello Jeff,
Monday, October 25, 2004, 8:09:20 PM, you wrote:
> On Oct 25, 2004, at 8:48 AM, Lukas Smith wrote:
>> D Kingma wrote:
>>> I just took a view at some PDO examples on the net and it looks
>>> promissing. The
>>> one thing that I would to see is that the fetch method accepts a
>>> cl
On Oct 25, 2004, at 8:48 AM, Lukas Smith wrote:
D Kingma wrote:
I just took a view at some PDO examples on the net and it looks
promissing. The
one thing that I would to see is that the fetch method accepts a
class name as
optional second parameter (when using PDO_FETCH_OBJ or
PDO_FETCH_LAZY) an
Hello Lukas,
Monday, October 25, 2004, 2:48:41 PM, you wrote:
> D Kingma wrote:
>> I just took a view at some PDO examples on the net and it looks promissing. The
>> one thing that I would to see is that the fetch method accepts a class name as
>> optional second parameter (when using PDO_FETCH_O
D Kingma wrote:
I just took a view at some PDO examples on the net and it looks promissing. The
one thing that I would to see is that the fetch method accepts a class name as
optional second parameter (when using PDO_FETCH_OBJ or PDO_FETCH_LAZY) and then
returns a new instance of the given class wi
I just took a view at some PDO examples on the net and it looks promissing. The
one thing that I would to see is that the fetch method accepts a class name as
optional second parameter (when using PDO_FETCH_OBJ or PDO_FETCH_LAZY) and then
returns a new instance of the given class with the given res
Hmm, for some reason, gmail decided that Lukas' mail didn't go to
internals, so my response didn't either...
-- Forwarded message --
From: Wez Furlong <[EMAIL PROTECTED]>
Date: Mon, 25 Oct 2004 11:52:33 +0100
Subject: Re: pdo [was Re: [PHP-DEV] PHP 5.1 roa
Georg Richter wrote:
I will be definetly be able to write this driver within the next 3
weeks. Beside the usual "overworked" reason, it's mainly the reason,
that pdo has several lacks.
Against the common consent from LinuxTag in June (on a meeting where
most of the db maintainers participated) , We
> +1 on unicode support. I think not having unicode support by default
> really hurts PHP in the enterprise where applications must almost always
> be internationalized. I know mbstring gets the job done, but it's
> really hard to evangelize PHP as a choice technology when you have to
> use an ex
Hi Georg,
I'm surprised at your email as the main design of PDO has been clear for
sometime, although I think lacking documentation has led to it being too
hard to understand *exactly* how it works (functionality wise), especially
the DB specific functionality. (no not trying to hint about the d
Richter" <[EMAIL PROTECTED]>
Cc: "George Schlossnagle" <[EMAIL PROTECTED]>; "Frank M. Kromann"
<[EMAIL PROTECTED]>; "internals" <[EMAIL PROTECTED]>; "Andi Gutmans"
<[EMAIL PROTECTED]>
Sent: Sunday, October 24, 2004 12:
On Sun, 24 Oct 2004 00:23:29 +0200, Georg Richter <[EMAIL PROTECTED]> wrote:
> I will be definetly be able to write this driver within the next 3
> weeks. Beside the usual "overworked" reason, it's mainly the reason,
> that pdo has several lacks.
I'm all ears.
> Against the common consent from L
Am Fr, den 22.10.2004 schrieb George Schlossnagle um 4:24:
Aloha namesake!
> If namesake-Georg doesn't get to it in the next 3 weeks, I'll probably
> take a whack at mysql 4.x driver in the second week of November.
>
I will be definetly be able to write this driver within the next 3
weeks. Bes
This one time, at band camp, Wez Furlong <[EMAIL PROTECTED]> wrote:
> Feature-wise, it's missing scrollable (eg: random access) cursors and
> Marcus' iterators (sorry Marcus).
So, when do we see iterators?
Kevin
-
"Democracy is two wolves and a lamb voting on what to have for lunch.
Lib
+1 on unicode support. I think not having unicode support by default
really hurts PHP in the enterprise where applications must almost always
be internationalized. I know mbstring gets the job done, but it's
really hard to evangelize PHP as a choice technology when you have to
use an extension to
On Oct 21, 2004, at 7:30 PM, Frank M. Kromann wrote:
Aside from that, PDO is very usable for the most common data access
patterns that you are likely to use in PHP.
Driver wise, we have a nice collection. The only major driver that we
are missing is mysql 4.x (we have 3.x).
If namesake-Georg doesn
> Aside from that, PDO is very usable for the most common data access
> patterns that you are likely to use in PHP.
>
> Driver wise, we have a nice collection. The only major driver that we
> are missing is mysql 4.x (we have 3.x).
The FBSQL driver is almost done, and when that happens Iøll star
> a) PDO support for most popular DBs. Maybe you can give a status report of
> where PDO is today and how much work it still requires? If it requires a
> lot of work maybe more people can join the effort. Also is there an online
> phpDoc of each DB API one can look at? I've looked at the source cod
20 matches
Mail list logo
