# PHP 5.2 Status Update

- Thread: https://externals.io/message/24367
- Original archive: https://news-web.php.net/php.internals/24367
- Started by Ilia Alshanetsky on 2006-07-13T15:03:11+00:00
- Messages: 16
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #24367 — Ilia Alshanetsky — 2006-07-13T15:03:11+00:00

URL: https://externals.io/message/24367#24367

It's been quite sometime since 5.2 was branched and looking over our  
"todo" majority of planned changes were made. Therefor I'd like to  
make an RC1 on Thursday next week and start the stabilization cycle  
of 5.2, so we can get a final in about 2 months. Once we start  
stabilization cycle, no new features will be accepted, so please use  
this week to commit any missing new features or major patches that  
have been agreed upon and not yet applied.


Ilia Alshanetsky
5.2 Release Master

---

## #24387 — Lukas Smith — 2006-07-15T10:12:12+00:00

URL: https://externals.io/message/24367#24387 · In reply to: #24367

Ilia Alshanetsky wrote:
> It's been quite sometime since 5.2 was branched and looking over our 
> "todo" majority of planned changes were made. Therefor I'd like to make 
> an RC1 on Thursday next week and start the stabilization cycle of 5.2, 
> so we can get a final in about 2 months. Once we start stabilization 
> cycle, no new features will be accepted, so please use this week to 
> commit any missing new features or major patches that have been agreed 
> upon and not yet applied.

I would also appreciate it if people could let me (or Ilia) know of any 
todo's already completed (or no longer planed) that are listed on the 
todo site:
http://oss.backendmedia.com/PhP52

Open todo items on that page are "assigned" to the following people:
Derick, Georg, Wez, Marcus, Pierre, Ilia, Dmitry, Rasmus, Gopal

regards,
Lukas

---

## #24396 — Marcus Boerger — 2006-07-15T13:24:26+00:00

URL: https://externals.io/message/24367#24396 · In reply to: #24387

Hello Lukas,

Saturday, July 15, 2006, 12:12:12 PM, you wrote:

> Ilia Alshanetsky wrote:
> > […]

> I would also appreciate it if people could let me (or Ilia) know of any 
> todo's already completed (or no longer planed) that are listed on the 
> todo site:
> http://oss.backendmedia.com/PhP52

> Open todo items on that page are "assigned" to the following people:
> Derick, Georg, Wez, Marcus, Pierre, Ilia, Dmitry, Rasmus, Gopal

I am also very pissed off that neither anybody cared for the upgrade
file nor did those accusing me personally extremley hard cared for
any further updating of that file....thanks again everybody...which
probably means we're back to normal operation modes after everyone
had a free shot...blablabla

Best regards,
 Marcus

---

## #24399 — Pierre — 2006-07-15T13:41:55+00:00

URL: https://externals.io/message/24367#24399 · In reply to: #24396

On Sat, 15 Jul 2006 15:24:26 +0200
helly@php.net (Marcus Boerger) wrote:

> Hello Lukas,
> 
> Saturday, July 15, 2006, 12:12:12 PM, you wrote:
> 
> > […]
> 
> > […]
> 
> > […]
> 
> I am also very pissed off that neither anybody cared for the upgrade
> file nor did those accusing me personally extremley hard cared for
> any further updating of that file....thanks again everybody...which
> probably means we're back to normal operation modes after everyone
> had a free shot...blablabla

And now try in english.

What are you trying to say?

For the record, I kept this file updated. And I did update it today
after having discussed with Ilia about the deadlines.

-- Pierre

---

## #24400 — Marian Kostadinov — 2006-07-15T14:20:56+00:00

URL: https://externals.io/message/24367#24400 · In reply to: #24367

I will just warn you that task 17 is assigned to no one but it seems it is
quite easy to be done.

---

## #24401 — Pierre — 2006-07-15T14:25:37+00:00

URL: https://externals.io/message/24367#24401 · In reply to: #24400

> I will just warn you that task 17 is assigned to no one but it seems it is
> quite easy to be done.


It is, to someone with a shell access :)

Also after I got a german "translation", it seems that Marcus was
talking about the README_UPGRADE file and not the TODO, go figure...

--Pierre

---

## #24460 — Derick Rethans — 2006-07-18T12:39:18+00:00

URL: https://externals.io/message/24367#24460 · In reply to: #24387

> Ilia Alshanetsky wrote:
> > […]

This caught be a bit by surprise as I was unavailabe the last two weeks, 
so I hope I am still in time with my todo items (enabling ext/date 
finally, and adding ext/filter with a symlink).

Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

---

## #24461 — Pierre — 2006-07-18T13:18:38+00:00

URL: https://externals.io/message/24367#24461 · In reply to: #24460

On Tue, 18 Jul 2006 14:39:18 +0200 (CEST)
derick@php.net (Derick Rethans) wrote:

> 
> 
> > […]
> 
> This caught be a bit by surprise as I was unavailabe the last two
> weeks, so I hope I am still in time with my todo items (enabling
> ext/date finally, and adding ext/filter with a symlink).


It seems that you are constantly and permanently do whatever you want.
That has to change.

We never agreed to enable *all* date classes and functions. The TODO,
online and approved since weeks, only mention date_sun_info and nothing
else.

Please revert before the first RC.

We have to solve this issue but in a reasonable and timed way, not with
your own and unilateral decisions.

Cheers,
-- Pierre

---

## #24468 — Ilia Alshanetsky — 2006-07-18T14:27:02+00:00

URL: https://externals.io/message/24367#24468 · In reply to: #24460

The date extension functionality can be enabled, but we need to  
rename the date class to avoid naming conflicts encountered with PHP  
5.1. There have been two names under consideration datetime and  
phpdate. Personally I'd prefer datetime, but after doing a quick  
search on google that seems like a popular name, already being used  
in various classes and libraries. phpdate (or PHPDate to comply with  
studly caps conventions ;-) ) on the otherhand is only used a very  
small number of times is minor classes therefor seems like a safe name.

If you chose PHPDate is the class name, I would no objections to  
including the functionality, assuming there are no technical merits  
for not including the extension.




> 
>
> > […]
>
> This caught be a bit by surprise as I was unavailabe the last two  
> weeks,
> so I hope I am still in time with my todo items (enabling ext/date
> finally, and adding ext/filter with a symlink).
>
> Derick
>
> -- 
> Derick Rethans
> http://derickrethans.nl | http://ez.no | http://xdebug.org
>
> -- 
> 
> 
>
>

Ilia Alshanetsky

---

## #24475 — Pierre — 2006-07-18T16:16:39+00:00

URL: https://externals.io/message/24367#24475 · In reply to: #24468

> The date extension functionality can be enabled, but we need to
> rename the date class to avoid naming conflicts encountered with PHP
> 5.1.

Wait, you are suggesting to enable this empty class and rename it? And
then he will rename it again for phph6? That's plain stupid and
insane.

I see again only one choice, enable the functions and disable the
class. It is still not what we planed since months for 5.2, but it is
the less problematic solutions.

Any other decisions should not be take in the hurry while releasing 5.2.

--Pierre

---

## #24477 — Ilia Alshanetsky — 2006-07-18T16:23:33+00:00

URL: https://externals.io/message/24367#24477 · In reply to: #24475

> 
> > […]
>
> Wait, you are suggesting to enable this empty class and rename it? And
> then he will rename it again for phph6? That's plain stupid and
> insane.

No. Derick wants to enable all the code in the date extension  
(methods of the date class and so on). The only way I can see us  
doing it is by renaming the 2 classes the extension defines to  
something that won't cause namespace problems.

Ilia Alshanetsky

---

## #24479 — Steph Fox — 2006-07-18T16:27:29+00:00

URL: https://externals.io/message/24367#24479 · In reply to: #24477

> 
>
> > […]
>
> No. Derick wants to enable all the code in the date extension
> (methods of the date class and so on). The only way I can see us
> doing it is by renaming the 2 classes the extension defines to
> something that won't cause namespace problems.

Hate to be a pain, but _what_ namespace problems? Where were all those bug 
reports the first time this was enabled? Why hasn't Date in PEAR changed its 
name to include the PEAR prefix?  Aren't these 'namespace problems' so much 
vaporware?

- Steph

>
> Ilia Alshanetsky

---

## #24478 — Matt Sicker — 2006-07-18T17:03:56+00:00

URL: https://externals.io/message/24367#24478 · In reply to: #24468

> The date extension functionality can be enabled, but we need to
> rename the date class to avoid naming conflicts encountered with PHP
> 5.1. There have been two names under consideration datetime and
> phpdate. Personally I'd prefer datetime, but after doing a quick
> search on google that seems like a popular name, already being used
> in various classes and libraries. phpdate (or PHPDate to comply with
> studly caps conventions ;-) ) on the otherhand is only used a very
> small number of times is minor classes therefor seems like a safe
> name.
>
> If you chose PHPDate is the class name, I would no objections to
> including the functionality, assuming there are no technical merits
> for not including the extension.
>
> 
> > […]
>
> Ilia Alshanetsky
It'd be nice to have a php namespace, wouldn't it? ;)

Maybe you might not want to include that class until PHP6.  Or, how 
about for backwards compatibility, you do prefix the class name with 
PHP, but when namespaces come into play, using the php namespace 
effectively removes the PHP prefix (e.g. PHPDate == php::Date).
-- 
Matt Sicker

---

## #24480 — Antony Dovgal — 2006-07-18T17:11:19+00:00

URL: https://externals.io/message/24367#24480 · In reply to: #24478

> It'd be nice to have a php namespace, wouldn't it? ;)

And that would help... how?
Two classes named "Date" will still clash, namespaces won't magically solve it.

> Maybe you might not want to include that class until PHP6.  Or, how 
> about for backwards compatibility, you do prefix the class name with 
> PHP, but when namespaces come into play, using the php namespace 
> effectively removes the PHP prefix (e.g. PHPDate == php::Date).


-- 
Wbr, 
Antony Dovgal

---

## #24485 — Derick Rethans — 2006-07-18T17:25:13+00:00

URL: https://externals.io/message/24367#24485 · In reply to: #24478

> Maybe you might not want to include that class until PHP6.  Or, how 
> about for backwards compatibility, you do prefix the class name with 
> PHP, but when namespaces come into play, using the php namespace 
> effectively removes the PHP prefix (e.g. PHPDate == php::Date).

If you rename it later it will definitely break at that moment, so 
that's a no-no.

Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

---

## #24683 — Matt Sicker — 2006-07-19T15:29:09+00:00

URL: https://externals.io/message/24367#24683 · In reply to: #24485

> 
> > […]
>
> If you rename it later it will definitely break at that moment, so
> that's a no-no.
>
> Derick
What I'm suggesting is that for PHP6, allow namespaces to be used in two 
different ways.  Example:

namespace foo {
  class bar {
    private $baz;
    static private $oof = 0;
    function __construct($baz) {
      $this->baz = $baz;
      $this->oof++; # I don't remember if you can do this, but you get
                    # the idea
    }
    static function getOof() {
      return $this->oof;
    }
  }
}

Then, we can access class `bar' like so:

$bar = new foo::bar('e.g.');
$oof = foo_bar::getOOf();

Or, you might just remove the underscore altogether so that we can 
introduce more useful namespaces (e.g. all the DOM classes can go in 
the DOM namespace).  Perhaps you could use the underscore for functions 
(!methods), thus also allowing many functions to be given their own 
namespaces (e.g. mysql_connect() == mysql::connect()).

Now since you would be able to declare something like:

using namespace mysql;

You'd be able to access its functions like so:

$db = connect('localhost', 'username', 'password') or 
die(header('HTTP/1.1 500 Internal Service Error'));

Now that might not be a good example considering mysql_* is old and 
crappy, and since using a mysqli example would be redundant since it 
already has a class, well, you know...

Anyhow, any feedback on this?  Or should I post this separately to get 
feedback since it regards PHP6?
-- 
Matt Sicker