PHP 5.1

And the much needed goto for the next one (5.2/5.5/6.0 or whatever it
will be) ?

+1 (for the "limited" version that Sara and Andi already worked out
last time this came up)

And please, no "this and that professor told me/wrote/said goto is
bad", and so on, replies =)

Amen :)

--Wez.

Hi,

2. PHP is all about the putting out text so nearly all objects created in
   PHP are meant to put something onto the generated pages. Thus i think i am
   not alone to suggest we put back the magic __toString function in place as
   we said when we dropped it's support from 5.0. Also it is very hard to
   explain why "echo $a . $obj" and "echo $a, $obj" output different things
   when one is an object. Both is pretty much against the spirit of PHP -
   easiness isn't it?

Especially with "echo $a . $obj" and "echo $a, $obj" it's really annoying.
Many people are concating when printing stuff and it's hard to explain why
the results differ...

4. I still want the ifsetor operator since it is very helpfull and again
   simplifies a lot of things.

+10

5. tons of other stuff i menationed offline and in public - since i lost
   the energy in tracking all that issues i guess the work and time in those
   wasn't worse the effort and they can wait anyway :-)

Is there progress with the new date stuff? I'd really like to have dates
before 1970.

johannes

Johannes Schlüter Mayflower GmbH / ThinkPHP
http://thinkphp.de http://blog.thinkphp.de

Marcus Boerger wrote:

4. I still want the ifsetor operator since it is very helpfull and again
   simplifies a lot of things.

+1

+1 for goto as well

regards,
Lukas

Hello Andi,

i forgot to mention one major problem. The current implementation of
extension dependency requires gnu-awk. If another awk implementation is
being used to generate php then the result is an immediate segfaulting
php binary. We should either make gawk checked by configure or rewrite
the exetension dependency by tables in the module struct so a dependent
extension doesn't get MINITed before its dependencies are initialized.
Probably we can go require way for 5.1 and have the other one done for
5.2.

Sunday, June 5, 2005, 7:18:26 PM, you wrote:

Hello Andi,

Saturday, June 4, 2005, 7:58:13 AM, you wrote:

Hey,

There have been a lot of questions and discussion regarding status of PHP 5.1.
In the past few weeks, many have been fixing lots of bugs and PDO seems to
have reached a pretty stable state.
In parallel, a lot of work has been done offline by Andrei, Dmitry and
others, to enable Unicode support in PHP and the Zend Engine.
I believe it is time now to move 5.1 forward at a much faster pace. I'd
like to roll a beta of it towards the end of next week such as Thursday
(giving a chance for some last minute fixes), and then hopefully RC within
a week or two.
Once we RC PHP 5.1, we should branch it off to PHP_5_1 and make HEAD the
Unicode development stream (merging Unicode changes into HEAD).

Hopefully, by going at this pace, we can have a pretty decent Unicode
version of PHP out there within a few months; and have PDO out there almost
immediately.

There are a few things i'd like to address before:

1. return by reference at c-level. This is already taken care of by dmitry
   who is currently working on a better patch than mine. However i need this
   to finalizy ArrayAccess interface. And i need a bit of a time to experiment
   with the result and maybe others want to give their input as well. At the
   moment the problem is that it cannot deal with references at all but there
   is already coe out with 5.0 that used that issue. So here is just somewhat
   work and testing needed.

2. PHP is all about the putting out text so nearly all objects created in
   PHP are meant to put something onto the generated pages. Thus i think i am
   not alone to suggest we put back the magic __toString function in place as
   we said when we dropped it's support from 5.0. Also it is very hard to
   explain why "echo $a . $obj" and "echo $a, $obj" output different things
   when one is an object. Both is pretty much against the spirit of PHP -
   easiness isn't it?

3. Is 5.1 coming out without filtering?

4. I still want the ifsetor operator since it is very helpfull and again
   simplifies a lot of things.

5. tons of other stuff i menationed offline and in public - since i lost
   the energy in tracking all that issues i guess the work and time in those
   wasn't worse the effort and they can wait anyway :-)

best regards
marcus

--
Best regards,
Marcus mailto:mail@marcus-boerger.de

Hello Andi,

Sunday, June 5, 2005, 9:13:52 PM, you wrote:

At 07:18 PM 6/5/2005 +0200, Marcus Boerger wrote:

2. PHP is all about the putting out text so nearly all objects created in
   PHP are meant to put something onto the generated pages. Thus i think i am
   not alone to suggest we put back the magic __toString function in place as
   we said when we dropped it's support from 5.0. Also it is very hard to
   explain why "echo $a . $obj" and "echo $a, $obj" output different things
   when one is an object. Both is pretty much against the spirit of PHP -
   easiness isn't it?

I thought you were going to write a patch up. Did you look into it?

Sure but i lost track of all my patches. Maybe i should start a list
that stores their review state so i can bug you more :-) Joke aside
i forgot to do that so thanks for the reminder. You'll find it attached.

3. Is 5.1 coming out without filtering?

Obviously not. (...). I want to try and work on an API proposal
first because I believe the API is where the issue is and not the coding...

Cool :-)

5. tons of other stuff i menationed offline and in public - since i lost
   the energy in tracking all that issues i guess the work and time in those
   wasn't worse the effort and they can wait anyway :-)

Yes (...). Most important is to make sure that PHP 5.1 is only better and not
worse than PHP 5.0, which I'm confident it is. And bringing PDO to the PHP
community, and allowing for Unicode work to fold into PHP dev tree is the
most important goal.

It is already much faster and i heared many people claiming 5.0 was to slow.
Also going for unicode seems very important.

marcus

Andi Gutmans wrote:

Obviously not. I don't see anyone actively working on it. I am hoping to
allocate resources to it in the near future but it'll come out when it
comes out, especially as it's an extension. It might even live in PECL
until everyone is happy with it. I want to try and work on an API
proposal first because I believe the API is where the issue is and not
the coding...

pecl/filter

The framework for it is in place. I'll try to get some actual filters
implemented this week. It's fine as a pecl extension for now. The
hooks have been in place for a while, so it shouldn't hold up 5.1.

-Rasmus

Hello Andi,

I have to strongly disagree with your ifsetor() comment. the use
for ifsetor is in no way eliminated with filtering.

I write very clean code and have taught all my developers to write
very clean code. We run the latest stable PHP version with maximum
error reporting. We do this so we can have more secure code with
fewer logic errors.

However, running in E_STRICT makes life rather miserable for simple
things such as accessing any array key that may or may not have been
included. I'm finding myself having the need for the ifsetor()
construct in all areas of programming - not just in _POST or _GET.

Even though you don't see yourself using it much, there are many
developers on this list who DO see the use for it, and there are
countless developers off this list who don't even know about it, but
would find it useful for migrating to E_ALL | E_STRICT error
reporting.

If there was any way to accommodate this with userland PHP code, I
would have already done it. However it is an engine level function
that has to be added to the core of PHP.

+ALot

Thanks.

--
Best regards,
Jason mailto:jason@ionzoft.com

Sunday, June 5, 2005, 3:13:52 PM, you wrote:

4. I still want the ifsetor operator since it is very helpfull and again
   simplifies a lot of things.

AG> I don't think ifsetor() shortcut is a big deal nor needed in PHP. I've said
AG> it numerous times. Once we have a filtering API there will be even less
AG> times where it will be applicable. Write an extra 10 characters or so...

AG> Andi

Hello Andi,

Sunday, June 5, 2005, 9:13:52 PM, you wrote:

At 07:18 PM 6/5/2005 +0200, Marcus Boerger wrote:

There are a few things i'd like to address before:

4. I still want the ifsetor operator since it is very helpfull and again
   simplifies a lot of things.

I don't think ifsetor() shortcut is a big deal nor needed in PHP. I've said
it numerous times. Once we have a filtering API there will be even less
times where it will be applicable. Write an extra 10 characters or so...

One of the major features of "ifsetor()" against "isset()?:" is that the first
can be twice as fast and is much more readable.

You also said numerous times it has nothing to do with input filtering :-)

marcus

Hi,

I'm +1 on the goto patch aswell. What was the consent on the limit of
a goto statement? Should it be able to jump outside a control block?
Can it jump anywhere?

Sincerely,
Olivier

+1 for the goto patch in 5.1

Quoting Ilia Alshanetsky ilia@prohost.org:

Yes, Sara made a patch for it..
http://pecl.org/patches/opcode_goto_5.1.0.diff
I don't know if this is the latest one or not.

+1 for the goto patch in 5.1

Ilia

--

+1 from here too

Andrey

Derick Rethans wrote:

I think, better (cleaner) way is extend 'break' and 'continue' to accept
string as label name in local scope. (like java :)).

Implement 'goto' with possibility to jump anywhere is a step backwards...

It's exactly the same as "break <label>"... goto can only jump in the
same scope with a label. So I don't see the difference.

Derick

It's not same, but it's same, look:

for( ... ) {
while( ... ) {
if(cond) goto exit;
}
}
exit:

is equivalent with:

exit:
for( ... ) {
while( ... ) {
if(cond) break exit;
}
}

or

for( ... ) {
while( ... ) {
if(cond) break 2;
}
}

goto <label>:

• we can jump into another loop, not so good

break/continue <label>

• little confusing syntax: break terminate executing labeled statement
  and transfer control to the next statement.

I don't need 'goto' but I prefer to extend break/continue. Always if
possible to set a flag in loop and use it to escape... :)

goto can help, but mostly create unreadable code...

--
Ondrej Ivanic
(ondrej@kmit.sk)

Why isn't is possible in userland? Is there any problem with using
this?

function ifsetor(&$var, $default = null) {
return isset($var) ? $var : $default;
}

echo ifsetor($a, 'foo');
echo $a, $b;
echo ifsetor($a, 'foo');
echo isset($a) ? 'is set' : 'not set';

expected result:

foo
Notice: Undefined variable: a in [...]
Notice: Undefined variable: b in [...]
foo
not set

actual result:

foo
Notice: Undefined variable: b in [...]
foo
not set

php does not issue a notice on using $a after having called ifsetor()
once. But further calls to isset() and ifsetor() keep returning the
expected results.

I'd assume, the missing notice is rather a bug than a feature. So
ifsetor() is possible in userland.

--
Sven

If it were possible at all to make a function accept unset variables without
generating a notice, I think ifsetor() shouldn't even be implemented. People
could then have the freedom to create such functions themselves. But
unfortunately, it doesn't seem to be possible, unless you'd suppress every
function call with a @, which I don't think is the way to go in this case.

So if it would be possible somehow to create your own isset()-like functions
in PHP-code, I'd say implement something that would make that possible, and
ingore the whole ifsetor() discussion from that moment on. People would be
free to write whatever function they'd prefer.

Ron

""Sara Golemon"" pollita@php.net wrote in message
news:38.CE.21296.BFD78A24@pb1.pair.com...

What about ifsetor for 5.1 ?

Would anybody be interested in a parameter for ifsetor() that would
treat
isset() as !empty() or an alternative function that achieves this? I
know
I'd love to see that. I use empty() a lot more than isset().

In the interrest of KISS, I'd leave the emptiness concept out of the
picture. Unlike isset-ness, an emptiness coalesce can be done in
userspace:

function firstNotEmpty() {
$vars = func_get_args();
foreach($vars as $var)
if (!empty($var)) return $var;
return NULL;
}

There's enough....contention over the undeniably useful and
not-implementable-in-userspace parts of this thread that it's not worth
muddling it up with things that are a simple matter to do in userspace.
It
doesn't matter that notempty() and ifsetor() could easily be implemented
by
the same opcode (just like isset/empty are).

-Sara

If it were possible at all to make a function accept unset variables without
generating a notice, I think ifsetor() shouldn't even be implemented. People
could then have the freedom to create such functions themselves. But
unfortunately, it doesn't seem to be possible, unless you'd suppress every
function call with a @, which I don't think is the way to go in this case.

So if it would be possible somehow to create your own isset()-like functions
in PHP-code, I'd say implement something that would make that possible, and
ingore the whole ifsetor() discussion from that moment on. People would be
free to write whatever function they'd prefer.

Voila!

function ifsetordefault( $array, $key, $default=null )
{
if( isset( $array[$key] ) )
{
return $array[$key];
}

return $default;

}

echo ifsetordefault( array( 1 => 'One', 2 => 'Two' ), 3, 'Three' );

Or if you prefer:

function ifsetpathordefault( $array, $path, $default=null, $sep='/' )
{
$pathBits = explode( $sep, $path );

$nest = $array;
foreach( $pathBits as $pathBit )
{
    if( !isset( $nest[$pathBit] ) )
    {
        return $default;
    }

    $nest = $nest[$pathBit];
}

return $nest;

}

And yet, I'd still prefer an internal function to do this MUCH MUCH MUCH
faster and then I'd also never need to run across the problem of naming
collisions with other libraries that implement the same code :)

Cheers,
Rob.

.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'

George Schlossnagle wrote:

It's for the benefit of all to make progress and not slow the release
cycle to a halt, especially for people who are looking forward to the
"major" features. We have some great stuff coming and it'll go bad if
we don't move the major pieces along.

I think this is an excellent idea. All of the features being debated
hotly now are extremely minor compared to good unicode support, and
given the broad effect of that change, getting it into HEAD and thus
into mainstream development usage would be a really good thing.

Yes, I am pretty sure the current discussions will pale in comparison to
the chaos that will be created when the Unicode stuff goes into HEAD! ;)

We need to get this code in front of more eyes as soon as possible so
people can start to share this pain.

-Rasmus

On Fri, 10 Jun 2005 09:07:26 +0200 (CEST)
derick@php.net (Derick Rethans) wrote:

I'll roll PHP 5.1 Beta 1 tomorrow. Hopefully we will then start
getting some very much needed feedback from the public for HEAD.

I'll put the date time stuff in today then. (Before you wake up
probably :). This will only replace strtotime() , we can discuss
what else we add later - not?

Indeed, I need some time after your commits, to update pecl/date
and see where is the place to put it.

That said, tomorrow is not end of next week, any reason to change
the planning? If yes, I should have beged Derick much more this
week to get this stuff in....

Regards,

--Pierre

I was hoping to get a little bit more PDO hacking done (see last
nights commits :) before the beta.
I'm closing on my new house today and moving this weekend.
I don't really want to delay the beta, but can we push it back until
next weekend?

--Wez.

I'll roll PHP 5.1 Beta 1 tomorrow. Hopefully we will then start getting some
very much needed feedback from the public for HEAD.

I'll put the date time stuff in today then. (Before you wake up probably :).
This will only replace strtotime() , we can discuss what else we add
later - not?

Derick

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

Andi Gutmans wrote:

I'll roll PHP 5.1 Beta 1 tomorrow. Hopefully we will then start getting some
very much needed feedback from the public for HEAD.

Will pecl_http be included?
(AFAIR something like that has been discussed earlier this year on this list)

We have the policy of not adding more very specialized extensions to the
PHP core distribution - those extensions should live in PECL.

regards,
Derick

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

Hi Andreas Korthaus, you wrote:

Will pecl_http be included? (AFAIR something like that has been
discussed earlier this year on this list)

Hm, I must have missed that...

Anyway it's still far away from stable - just compare the
count of tests against the amount of functionality provided.

Regards,

Michael - < mike(@)php.net