Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #10876 > unrolled thread

the changeover to mysqli

Back to article view | Back to comp.lang.php

Contents

  the changeover to mysqli richard <noreply@example.com> - 2013-09-24 22:38 -0400
    Re: the changeover to mysqli Jerry Stuckle <jstucklex@attglobal.net> - 2013-09-24 23:48 -0400
      Re: the changeover to mysqli Adam Harvey <usenet@adamharvey.name> - 2013-09-25 17:29 +0000
        Re: the changeover to mysqli richard <noreply@example.com> - 2013-09-25 15:01 -0400
          Re: the changeover to mysqli Adam Harvey <usenet@adamharvey.name> - 2013-09-25 19:28 +0000
            Re: the changeover to mysqli richard <noreply@example.com> - 2013-09-25 16:21 -0400
              Re: the changeover to mysqli Christoph Michael Becker <cmbecker69@arcor.de> - 2013-09-25 22:36 +0200
              Re: the changeover to mysqli Adam Harvey <usenet@adamharvey.name> - 2013-09-25 20:38 +0000
                Re: the changeover to mysqli richard <noreply@example.com> - 2013-09-25 20:16 -0400
              Re: the changeover to mysqli Denis McMahon <denismfmcmahon@gmail.com> - 2013-09-25 21:11 +0000
              Re: the changeover to mysqli Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2013-09-25 17:46 -0400
                Re: the changeover to mysqli Twayne <nobody@spamcop.net> - 2013-09-26 18:28 -0400
          Re: the changeover to mysqli Tim Streater <timstreater@greenbee.net> - 2013-09-25 22:38 +0100
            Re: the changeover to mysqli Christoph Michael Becker <cmbecker69@arcor.de> - 2013-09-25 23:58 +0200
              Re: the changeover to mysqli Jerry Stuckle <jstucklex@attglobal.net> - 2013-09-25 22:53 -0400
                Re: the changeover to mysqli Christoph Michael Becker <cmbecker69@arcor.de> - 2013-09-26 20:59 +0200
                  Re: the changeover to mysqli Jerry Stuckle <jstucklex@attglobal.net> - 2013-09-26 15:41 -0400
              Re: the changeover to mysqli Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-09-27 01:09 +0200
        Re: the changeover to mysqli Jerry Stuckle <jstucklex@attglobal.net> - 2013-09-25 15:34 -0400
          Re: the changeover to mysqli Fiver <numeralfive@gmail.com> - 2013-09-25 23:32 +0200
            Re: the changeover to mysqli Jerry Stuckle <jstucklex@attglobal.net> - 2013-09-25 22:54 -0400
              Re: the changeover to mysqli Fiver <numeralfive@gmail.com> - 2013-09-26 05:30 +0200
                Re: the changeover to mysqli Curtis Dyer <dyer85@gmail.com> - 2013-09-26 06:13 +0000
              Re: the changeover to mysqli Twayne <nobody@spamcop.net> - 2013-09-26 18:32 -0400
    Re: the changeover to mysqli Scott Johnson <noonehome@chalupasworld.com> - 2013-09-24 21:14 -0700
    Re: the changeover to mysqli David Robley <me@home.invalid> - 2013-09-25 13:50 +0930

Page 1 of 2  [1] 2  Next page →

#10876 — the changeover to mysqli

The big push is on for scripters to change to to i.
But nobody knows when that's going to happen.
As far as I can see, the "horses mouth" has not changed.
the online resource manual STILL and totally, discusses mysql.
They need to be making new pages that discuss what the changes are and how
one is to make the changes properly.

Mr. Yates pointed out that changing over hundreds of pages can be a tedious
task. They need to literally rewrite the book.
NOW!
And define when the changeover is to happen.


For now anyway, my little site only requires a few short pages and that can
easily be changed.

[toc] | [next] | [standalone]

#10878

On 9/24/2013 10:38 PM, richard wrote:
> The big push is on for scripters to change to to i.
> But nobody knows when that's going to happen.
> As far as I can see, the "horses mouth" has not changed.
> the online resource manual STILL and totally, discusses mysql.
> They need to be making new pages that discuss what the changes are and how
> one is to make the changes properly.
>
> Mr. Yates pointed out that changing over hundreds of pages can be a tedious
> task. They need to literally rewrite the book.
> NOW!
> And define when the changeover is to happen.
>
>
> For now anyway, my little site only requires a few short pages and that can
> easily be changed.
>

The PTB have already indicated the mysql interface is deprecated.  It 
will be removed at some future time.  That right there is enough to 
start converting.

Considering PHP 6.0 is way behind its original proposed release date, 
they probably don't know, either.

But then we know you're too stubborn and won't change until your "little 
site" breaks.  Then you'll come crying here that the new release broke 
your site.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#10888

On Tue, 24 Sep 2013 23:48:20 -0400, Jerry Stuckle wrote:
> Considering PHP 6.0 is way behind its original proposed release date,
> they probably don't know, either.

To nitpick, there is no PHP 6.0. In the form it was originally proposed, 
it was dropped back in 2010 when php-src trunk was moved to the 
experimental/first-unicode-implementation branch and trunk was rebased off 
the then PHP 5.4 branch.

As for ext/mysql's removal, we'll see what happens. I deliberately left 
that open ended when I wrote the deprecation RFC, because it really 
depends on how quickly people move to the better alternatives. I don't 
think it'll happen in 5.6 next year — as this thread demonstrates, there 
are still too many people using it right now, but it is going to happen at 
some point. Maintaining three separate extensions for the same database is 
insane.

Adam

[toc] | [prev] | [next] | [standalone]

#10889

On Wed, 25 Sep 2013 17:29:18 +0000 (UTC), Adam Harvey wrote:

> On Tue, 24 Sep 2013 23:48:20 -0400, Jerry Stuckle wrote:
>> Considering PHP 6.0 is way behind its original proposed release date,
>> they probably don't know, either.
> 
> To nitpick, there is no PHP 6.0. In the form it was originally proposed, 
> it was dropped back in 2010 when php-src trunk was moved to the 
> experimental/first-unicode-implementation branch and trunk was rebased off 
> the then PHP 5.4 branch.
> 
> As for ext/mysql's removal, we'll see what happens. I deliberately left 
> that open ended when I wrote the deprecation RFC, because it really 
> depends on how quickly people move to the better alternatives. I don't 
> think it'll happen in 5.6 next year — as this thread demonstrates, there 
> are still too many people using it right now, but it is going to happen at 
> some point. Maintaining three separate extensions for the same database is 
> insane.
> 
> Adam

Ain;t it amazing how the internet evolved over the years?
At first, everyone used tables for anything and everything.
Then they learned about CSS and applied it.
Then they learned how to manipulate the displayed page using server side
scripting such as PHP.
And upwards to sql and tables.

Then, PTB want to upgrade the system but are reluctant to do so because the
old system is till widely used, and abused.

Hell, if that theory held true, we'd still be using tables.
So why don't they just make the change, be done with it and let the people
have the option of using either.

Let's face it, html has deprecated a ton of things which are still in use.
Why? because a hoard of people refuse to upgrade their systems.

[toc] | [prev] | [next] | [standalone]

#10890

On Wed, 25 Sep 2013 15:01:28 -0400, richard wrote:
> Hell, if that theory held true, we'd still be using tables.
> So why don't they just make the change, be done with it and let the
> people have the option of using either.

The change you refer to happened nine years ago, when PDO and mysqli were 
bundled into the release of PHP 5.0.0. You've had the option of using 
either since then.

Make no mistake: ext/mysql will be removed at a future date. The manual 
text isn't hyperbole. All I'm saying is that it almost certainly won't be 
next year, but that it will be soon enough that writing new code to use 
ext/mysql is unwise.

Adam

[toc] | [prev] | [next] | [standalone]

#10892

On Wed, 25 Sep 2013 19:28:38 +0000 (UTC), Adam Harvey wrote:

> On Wed, 25 Sep 2013 15:01:28 -0400, richard wrote:
>> Hell, if that theory held true, we'd still be using tables.
>> So why don't they just make the change, be done with it and let the
>> people have the option of using either.
> 
> The change you refer to happened nine years ago, when PDO and mysqli were 
> bundled into the release of PHP 5.0.0. You've had the option of using 
> either since then.
> 
> Make no mistake: ext/mysql will be removed at a future date. The manual 
> text isn't hyperbole. All I'm saying is that it almost certainly won't be 
> next year, but that it will be soon enough that writing new code to use 
> ext/mysql is unwise.
> 
> Adam

then why hasn't the horses mouth followed their own demands?
Of all the reference material I've seen on their site, all examples refer
to mysql, NOT mysqli.

[toc] | [prev] | [next] | [standalone]

#10893

richard wrote:

> Of all the reference material I've seen on their site, all examples
> refer to mysql, NOT mysqli.

Then you should have a look at the appropriate part of the documentation
on php.net, i.e. the book about the MySQL Improved Extension[1].

[1] <http://php.net/manual/en/book.mysqli.php>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#10894

On Wed, 25 Sep 2013 16:21:25 -0400, richard wrote:
> then why hasn't the horses mouth followed their own demands?
> Of all the reference material I've seen on their site, all examples
> refer to mysql, NOT mysqli.

If you can provide links to pages on php.net that still recommend mysql 
over mysqli or PDO, I will happily fix them up to recommend more modern 
code.

Note that the reference documents for mysql_* functions already have 
warnings at the top of each page recommending alternatives, and have to 
include examples of the deprecated functions to be useful.

Adam

[toc] | [prev] | [next] | [standalone]

#10900

On Wed, 25 Sep 2013 20:38:15 +0000 (UTC), Adam Harvey wrote:

> On Wed, 25 Sep 2013 16:21:25 -0400, richard wrote:
>> then why hasn't the horses mouth followed their own demands?
>> Of all the reference material I've seen on their site, all examples
>> refer to mysql, NOT mysqli.
> 
> If you can provide links to pages on php.net that still recommend mysql 
> over mysqli or PDO, I will happily fix them up to recommend more modern 
> code.
> 
> Note that the reference documents for mysql_* functions already have 
> warnings at the top of each page recommending alternatives, and have to 
> include examples of the deprecated functions to be useful.
> 
> Adam

Since you're the man in charge, then I'll make a simple resolution.
Create a page with two columns.
Column 1 has the mysql item, while column 2 has the corresponding mysqli
item.
Then link column 2 to the new item "manual".

for instance:

mysql_free_result()   ---->>  mysqli_free_result()
http://php.net/manual/en/function.mysql-free-result.php

I had a look at the mysql stuff listed in the left column.
As you say, the replacement code is shown.
But I think a list showing the new code as well would be better.

[toc] | [prev] | [next] | [standalone]

#10895

On Wed, 25 Sep 2013 16:21:25 -0400, richard wrote:

> then why hasn't the horses mouth followed their own demands?

Please clarify. What do you mean by "horses mouth"?

There is only one horses mouth for php, and that is php.net. All the 
reference material on php.net for mysql_* warns that it is deprecated and 
that you should use mysqli_* or PDO_MySQL.

e.g. on http://uk3.php.net/manual/en/intro.mysql.php the introduction to 
mysql is as follows:

This extension is deprecated as of PHP 5.5.0, and is not recommended for 
writing new code as it will be removed in the future. Instead, either the 
mysqli or PDO_MySQL extension should be used. See also the MySQL API 
Overview for further help while choosing a MySQL API. 

That is what the horses mouth says, so whatever horse you think is 
talking to you, it's the wrong horse.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#10898

On Wednesday 25 September 2013 16:21, in comp.lang.php, richard
(noreply@example.com) wrote:

> On Wed, 25 Sep 2013 19:28:38 +0000 (UTC), Adam Harvey wrote:
> 
>> On Wed, 25 Sep 2013 15:01:28 -0400, richard wrote:
>>> Hell, if that theory held true, we'd still be using tables.
>>> So why don't they just make the change, be done with it and let the
>>> people have the option of using either.
>> 
>> The change you refer to happened nine years ago, when PDO and mysqli were
>> bundled into the release of PHP 5.0.0. You've had the option of using
>> either since then.
>> 
>> Make no mistake: ext/mysql will be removed at a future date. The manual
>> text isn't hyperbole. All I'm saying is that it almost certainly won't be
>> next year, but that it will be soon enough that writing new code to use
>> ext/mysql is unwise.
>> 
>> Adam
> 
> then why hasn't the horses mouth followed their own demands?
> Of all the reference material I've seen on their site, all examples refer
> to mysql, NOT mysqli.

Richard, forget that we even suggested that you be proactive about your
site. You don't need to take any action now; you can wait until your
provider switches to whatever PHP release that removes the mysql_
interface, and then make your changes.

Of course, your site will be unavailable for the duration of your
changeover, and you won't be able to easily regression test the code
changes, but those are trivialities. I'm sure that you won't be off the air
for more than a few weeks.

As for the examples in the PHP documentation, I notice that most of them
are "contributed" by outsiders, as comments. I'm not certain that I'd trust
most of those examples to be representative of how the PHP maintainers
recommend that you do things.

HTH
-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#10913

On 2013-09-25 5:46 PM, Lew Pitcher wrote:
> On Wednesday 25 September 2013 16:21, in comp.lang.php, richard
...
>
> Richard, forget that we even suggested that you be proactive about your
> site. You don't need to take any action now; you can wait until your
> provider switches to whatever PHP release that removes the mysql_
> interface, and then make your changes.

Says you; you're pissed because he's wise enough to see the bigger 
picture by now. Actually I'm beginning to wonder about your own 
experience and ability w/r to databases, PHP and how they're used.

If your servers don't let you determine the version of PHP you use and 
would automatically change everything to their latest install, then I 
suggest you need a server-admin where you get better support and 
communications. Any major server changes should be communicated to you 
BEFORE they happen, or at least be listed on the site - mine sends 
e-mails to me. And it's a business oriented website with excellent 
support areas who respond quickly to questions that aren't in their FAQs.

>
> Of course, your site will be unavailable for the duration of your
> changeover, and you won't be able to easily regression test the code
> changes, but those are trivialities. I'm sure that you won't be off the air
> for more than a few weeks.

It's pretty much irrelevant what you think based on your postings in 
this thread.

>
> As for the examples in the PHP documentation, I notice that most of them
> are "contributed" by outsiders, as comments. I'm not certain that I'd trust
> most of those examples to be representative of how the PHP maintainers
> recommend that you do things.


>
> HTH
>

[toc] | [prev] | [next] | [standalone]

#10897

In article <1cun3xxz7nbpj.zop5ye5ou0f7$.dlg@40tude.net>,
 richard <noreply@example.com> wrote:

> So why don't they just make the change, be done with it and let the people
> have the option of using either.

They have made the change; they've added mysqli.
Why don't you move to it?

> Let's face it, html has deprecated a ton of things which are still in use.
> Why? because a hoard of people refuse to upgrade their systems.

You mean, update their web pages. Fat chance of that happening. And 
because browsers still support almost everything that was ever 
introduced, bar a couple of minor things, I see no reason, by and large, 
to do so either. I just use the HTML5 doctype to ensure standards mode.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#10899

Tim Streater wrote:

> In article <1cun3xxz7nbpj.zop5ye5ou0f7$.dlg@40tude.net>,
> richard <noreply@example.com> wrote:
> 
>> Let's face it, html has deprecated a ton of things which are still in
>> use.
>> Why? because a hoard of people refuse to upgrade their systems.
> 
> You mean, update their web pages. Fat chance of that happening. And
> because browsers still support almost everything that was ever
> introduced, bar a couple of minor things, I see no reason, by and large,
> to do so either. I just use the HTML5 doctype to ensure standards mode.

And that is exactly the reason, why those deprecated features won't be
removed--because it would break too many existing sites.  If there were
less websites relying on obsolete features, the browser's could be
purged, which would be beneficial to ease further development.

The situation is similar with regard to the original MySQL extension.
Cf. <https://wiki.php.net/rfc/mysql_deprecation>.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#10901

On 9/25/2013 5:58 PM, Christoph Michael Becker wrote:
> Tim Streater wrote:
>
>> In article <1cun3xxz7nbpj.zop5ye5ou0f7$.dlg@40tude.net>,
>> richard <noreply@example.com> wrote:
>>
>>> Let's face it, html has deprecated a ton of things which are still in
>>> use.
>>> Why? because a hoard of people refuse to upgrade their systems.
>>
>> You mean, update their web pages. Fat chance of that happening. And
>> because browsers still support almost everything that was ever
>> introduced, bar a couple of minor things, I see no reason, by and large,
>> to do so either. I just use the HTML5 doctype to ensure standards mode.
>
> And that is exactly the reason, why those deprecated features won't be
> removed--because it would break too many existing sites.  If there were
> less websites relying on obsolete features, the browser's could be
> purged, which would be beneficial to ease further development.
>
> The situation is similar with regard to the original MySQL extension.
> Cf. <https://wiki.php.net/rfc/mysql_deprecation>.
>

No, they WILL BE removed.  There has been plenty of time for people to 
move to the new interface(s).  Smart programmers have done so.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#10906

Jerry Stuckle wrote:

> On 9/25/2013 5:58 PM, Christoph Michael Becker wrote:
>> Tim Streater wrote:
>>
>>> In article <1cun3xxz7nbpj.zop5ye5ou0f7$.dlg@40tude.net>,
>>> richard <noreply@example.com> wrote:
>>>
>>>> Let's face it, html has deprecated a ton of things which are still in
>>>> use.
>>>> Why? because a hoard of people refuse to upgrade their systems.
>>>
>>> You mean, update their web pages. Fat chance of that happening. And
>>> because browsers still support almost everything that was ever
>>> introduced, bar a couple of minor things, I see no reason, by and large,
>>> to do so either. I just use the HTML5 doctype to ensure standards mode.
>>
>> And that is exactly the reason, why those deprecated features won't be
>> removed--because it would break too many existing sites.  If there were
>> less websites relying on obsolete features, the browser's could be
>> purged, which would be beneficial to ease further development.
>>
>> The situation is similar with regard to the original MySQL extension.
>> Cf. <https://wiki.php.net/rfc/mysql_deprecation>.
>>
> 
> No, they WILL BE removed.

I didn't want to say that the mysql extension will not be removed, but
rather that the process of deprecating it apparently was not so easy,
just because many websites/programs are still using the extension, even
if its use has been discouraged (long?) before PHP 5.5.

>                            There has been plenty of time for people to
> move to the new interface(s).  Smart programmers have done so.

Agreed.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#10907

On 9/26/2013 2:59 PM, Christoph Michael Becker wrote:
> Jerry Stuckle wrote:
>
>> On 9/25/2013 5:58 PM, Christoph Michael Becker wrote:
>>> Tim Streater wrote:
>>>
>>>> In article <1cun3xxz7nbpj.zop5ye5ou0f7$.dlg@40tude.net>,
>>>> richard <noreply@example.com> wrote:
>>>>
>>>>> Let's face it, html has deprecated a ton of things which are still in
>>>>> use.
>>>>> Why? because a hoard of people refuse to upgrade their systems.
>>>>
>>>> You mean, update their web pages. Fat chance of that happening. And
>>>> because browsers still support almost everything that was ever
>>>> introduced, bar a couple of minor things, I see no reason, by and large,
>>>> to do so either. I just use the HTML5 doctype to ensure standards mode.
>>>
>>> And that is exactly the reason, why those deprecated features won't be
>>> removed--because it would break too many existing sites.  If there were
>>> less websites relying on obsolete features, the browser's could be
>>> purged, which would be beneficial to ease further development.
>>>
>>> The situation is similar with regard to the original MySQL extension.
>>> Cf. <https://wiki.php.net/rfc/mysql_deprecation>.
>>>
>>
>> No, they WILL BE removed.
>
> I didn't want to say that the mysql extension will not be removed, but
> rather that the process of deprecating it apparently was not so easy,
> just because many websites/programs are still using the extension, even
> if its use has been discouraged (long?) before PHP 5.5.
>
>>                             There has been plenty of time for people to
>> move to the new interface(s).  Smart programmers have done so.
>
> Agreed.
>

It always takes a long time to remove something which has been used for 
years - no matter what the product/language/OS/whatever.  I think ZEND 
has been very proactive in warning people about it going away, and will 
continue to do so for a while to come before it is actually removed.

Unfortunately, there will still be a lot of sites (especially CMS's) 
where the webmaster is not a programmer, and so won't see the message 
until it's too late.  Sure, the CMS's can change their code to not use 
(or give the option to use) mysql_(), but many of those same webmasters 
don't update their sites because they don't see a need to.

So you can bet that eventually many sites will break - just like they 
did when PHP changed the default for register_globals, changed session 
variable handling and any number of other changes - despite the fact 
these had been deprecated for years before being removed.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#10917

Christoph Michael Becker wrote:

> Tim Streater wrote:
>> In article <1cun3xxz7nbpj.zop5ye5ou0f7$.dlg@40tude.net>,
>> richard <noreply@example.com> wrote:
>>> Let's face it, html has deprecated a ton of things which are still in
>>> use. Why? because a hoard of people refuse to upgrade their systems.
>> 
>> You mean, update their web pages. Fat chance of that happening. And
>> because browsers still support almost everything that was ever
>> introduced, bar a couple of minor things, I see no reason, by and large,
>> to do so either. I just use the HTML5 doctype to ensure standards mode.
> 
> And that is exactly the reason, why those deprecated features won't be
> removed--because it would break too many existing sites.  If there were
> less websites relying on obsolete features, the browser's could be
> purged, which would be beneficial to ease further development.
> 
> The situation is similar with regard to the original MySQL extension.
> Cf. <https://wiki.php.net/rfc/mysql_deprecation>.

The most important issue with the mysql extension that appears to be 
overlooked by all discussing so far is not that the extension will be 
removed later.  It is the fact that it is patently inefficient and insecure 
by comparison *right now*.  It has no native support for

- reading a result into an array *without* a loop (there is no
  mysql_fetchall)
- transactions
- Prepared Statements

and so on.

It is no longer officially supported by the MySQL vendor, Oracle.  As a 
result, it does not support natively (if at all; I have not tried) features 
introduced in MySQL 5.1 and above.  The current MySQL stable version is 5.6.

The latest bugfix of php_mysql.c was in 2011:

<http://git.php.net/?p=php-src.git;a=history;f=ext/mysql/php_mysql.c;h=88bb9ab21ef9fb15a147fc776569e8548e0be83b;hb=HEAD>

That was 2 years ago.  An eternity in computer technology, considering that 
updates and especially security updated for maintained software are released 
on a daily (e.g., security.debian.org) to at most bimonthly (e.g., Firefox) 
basis.

See also <http://php.net/manual/en/mysqlinfo.api.choosing.php>

Deprecation is not merely a documentation status with PHP; it has 
consequences for running PHP code:

<http://git.php.net/?p=php-src.git;a=commitdiff;h=b7091aaf0137d97cf4aa4a402ec50b3946d369c0>

IOW, E_DEPRECATED warnings may pile up in your log and make the application 
and the server run slower than it could be.

Insofar your well-intentioned comparison with deprecated HTML features is 
missing the point.

Anyhow, I am afraid that none of our arguments will be convincing enough for 
*seemingly* natural-born ignorants like “richard”.  So why not save free-
time and just stop feeding the likely troll – both of them?


PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#10891

On 9/25/2013 1:29 PM, Adam Harvey wrote:
> On Tue, 24 Sep 2013 23:48:20 -0400, Jerry Stuckle wrote:
>> Considering PHP 6.0 is way behind its original proposed release date,
>> they probably don't know, either.
>
> To nitpick, there is no PHP 6.0. In the form it was originally proposed,
> it was dropped back in 2010 when php-src trunk was moved to the
> experimental/first-unicode-implementation branch and trunk was rebased off
> the then PHP 5.4 branch.
>

No, there is no PHP 6.0 NOW.  But there will be eventually - just maybe 
not in the form it was originally proposed.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#10896

On 2013-09-25 21:34, Jerry Stuckle wrote:
> No, there is no PHP 6.0 NOW.  But there will be eventually [...]

Right after the release of Perl 6, presumably.

SCNR,
5er

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web