Rasmus Lerdorf wrote:
Pierre, I agree with you that it was a bad idea to turn on the stub date
class in the final release candidate giving people less than a week to
notice that we now conflict with a common pear class. We get all the
breakage and none of the benefits and nobody had any time
Helgi Þormar wrote:
Rasmus mentioned that no PEAR person tested the final RC and all that and
thus this issue wasn't found ... Correct me if I'm wrong, but wasn't that
change done between the final RC and the official release ?
Nope, this change was in RC6:
http://cvs.php.net/diff.php/php-src/
On Fri, 25 Nov 2005 15:16:43 +0800, Alan Knowles wrote:
> This one's a bit more annoying than usual ;)
>
> It will basically break application that depends on the Date package
> (eg. most of my code as DataObjects uses it internally).. Do we really
> need another barrier to upgrade to 5.*?
Yeah
This one's a bit more annoying than usual ;)
It will basically break application that depends on the Date package
(eg. most of my code as DataObjects uses it internally).. Do we really
need another barrier to upgrade to 5.*?
Regards
Alan
On Fri, 2005-11-25 at 07:55 +0100, Pierre wrote:
> On Thu
On Thu, 24 Nov 2005 21:23:17 -0800
[EMAIL PROTECTED] (Rasmus Lerdorf) wrote:
> Pierre, I agree with you that it was a bad idea to turn on the stub
> date class in the final release candidate giving people less than a
> week to notice that we now conflict with a common pear class. We get
> all the
Pierre, I agree with you that it was a bad idea to turn on the stub date
class in the final release candidate giving people less than a week to
notice that we now conflict with a common pear class. We get all the
breakage and none of the benefits and nobody had any time to prepare the
pear sid
Ok, so I know this is already close to a flamewar and I don't mean to add
to that, but how difficult would it be to select a naming scheme, shove
all the functions into and alias the non-conforming names to those
functions. New code would be consistent, old code would work. And then
at PHP 8
[EMAIL PROTECTED] wrote:
Perhaps this has already been proposed and I missed it as I'm new to the
list, but why not set a release in the future, say PHP8, in which there
will be no holds barred about breaking bc? Everyone would know that this
upcomming release would be the one that resolves all i
This is a update of the get_headers patch i sent in a long time ago and was
ignored. Patch is written with the latest cvs snapshot of 5.1. Hope it makes it
way to 5.1.1
Info:
mixed get_headers ( string url [, bool format | string header [,resource
context]])
2nd arg can eather be bool or str
On Thu, 24 Nov 2005 21:52:28 -0500
[EMAIL PROTECTED] (Ilia Alshanetsky) wrote:
^
> Pierre first of all I put the change in after a discussion with Derick
> and a number of the while you were present btw. This was done to
> declare the date class for "future" proofing and allow isolation of
> date
Pierre wrote:
> On Thu, 24 Nov 2005 16:15:04 -0800
> [EMAIL PROTECTED] (Andi Gutmans) wrote:
>
>
>>Hey,
>>
>>Just wanted to thank everyone who helped get PHP 5.1 out of the door
>>after a lot of efforts.
>>Special thanks to Steph who stepped up to make the upgrading guide
>>happen. I think this
On Thu, 24 Nov 2005 16:15:04 -0800
[EMAIL PROTECTED] (Andi Gutmans) wrote:
> Hey,
>
> Just wanted to thank everyone who helped get PHP 5.1 out of the door
> after a lot of efforts.
> Special thanks to Steph who stepped up to make the upgrading guide
> happen. I think this should become a standa
Well, safe_mode could prevent someone of doing a
shell_exec("cat /home/otheruser/web/config.php");
open_basedir can't do the same thing.
disabled_functions=shell_exec, etc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yep, completely right. We came to the conclusion a long time ago that
safe_mode isn't safe, and keeping it around is just going to continue
giving people a false sense of security (and PHP a bad name).
Andi
At 02:12 PM 11/24/2005, Rasmus Lerdorf wrote:
Peter Brodersen wrote:
Well, safe_mode
Hey,
Just wanted to thank everyone who helped get PHP 5.1 out of the door
after a lot of efforts.
Special thanks to Steph who stepped up to make the upgrading guide
happen. I think this should become a standard for future PHP releases.
Also thanks to Ilia who picked up the last few rounds of PH
Peter Brodersen wrote:
Well, safe_mode could prevent someone of doing a
shell_exec("cat /home/otheruser/web/config.php");
open_basedir can't do the same thing.
We were in a continual losing race against that sort of thing though.
In pretty much every single release there have been ways to do t
Hi,
On Thu, 24 Nov 2005 09:11:53 -0800
Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> > I'm not looking for any near-safe_mode-substitution. I'm more
> > concerned about the deployment of PHP6 at shared hosts.
> These shared hosts really should be using open_basedir. We have
> confused them by hav
Andi Gutmans wrote:
I thought 6.9 was per-process persistent
Yeah, they are, but they are still in the same family, I think. If you
have a config.inc, for example, that populates a $config array. If you
make that persistent you only have to load it once and it will be
available to each req
I thought 6.9 was per-process persistent
At 11:50 AM 11/24/2005, Rasmus Lerdorf wrote:
Andreas Korthaus wrote:
Rasmus Lerdorf wrote:
That's way outside the scope of what we have planned for PHP 6 and
I can pretty much guarantee it won't happen. The SRM-like thing
doesn't need to be part of
You could use a system like memcached. This kind of thing isn't
really in the scope of doing it in PHP per-se.
At 11:19 AM 11/24/2005, Andreas Korthaus wrote:
Rasmus Lerdorf wrote:
That's way outside the scope of what we have planned for PHP 6 and
I can pretty much guarantee it won't happen.
Leonardo Pedretti wrote:
On Thursday 24 November 2005 15:39, Rasmus Lerdorf wrote:
D. Dante Lorenso wrote:
All,
I have been trying to use PHP 5.0.5 for all my programming tasks
including replacing many stand-alone Java servers. I've been successful
to a degree, but I'm seriously missing Java
Andreas Korthaus wrote:
Rasmus Lerdorf wrote:
That's way outside the scope of what we have planned for PHP 6 and I
can pretty much guarantee it won't happen. The SRM-like thing doesn't
need to be part of PHP though. Anybody can build such a beast.
What about something like a "persistent s
Actually, three: code blocks, interpolation of complex variables, and
string indexing.
- Andrei
On Nov 24, 2005, at 3:22 AM, Jani Taskinen wrote:
True. But having two purposes for {} is not good either.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
Hello Wez,
i already see the whole world laughing at us :-)
marcus
Thursday, November 24, 2005, 5:43:48 PM, you wrote:
> Agreed; I see no reason to call it break (that makes it even more
> confusing), and limiting jumps to one direction only is dumb; there is
> no technical reason to do that.
Rasmus Lerdorf wrote:
That's way outside the scope of what we have planned for PHP 6 and I can
pretty much guarantee it won't happen. The SRM-like thing doesn't need
to be part of PHP though. Anybody can build such a beast.
What about something like a "persistent superglobal"? The idea is
On Thursday 24 November 2005 15:39, Rasmus Lerdorf wrote:
> D. Dante Lorenso wrote:
> > All,
> >
> > I have been trying to use PHP 5.0.5 for all my programming tasks
> > including replacing many stand-alone Java servers. I've been successful
> > to a degree, but I'm seriously missing Java Threads.
D. Dante Lorenso wrote:
All,
I have been trying to use PHP 5.0.5 for all my programming tasks
including replacing many stand-alone Java servers. I've been successful
to a degree, but I'm seriously missing Java Threads. I've written some
code which uses SHM, Sockets, IPC, and PCNTL, but it's
All,
I have been trying to use PHP 5.0.5 for all my programming tasks
including replacing many stand-alone Java servers. I've been successful
to a degree, but I'm seriously missing Java Threads. I've written some
code which uses SHM, Sockets, IPC, and PCNTL, but it's not as clean and
robust
Christian Schneider wrote:
Sara Golemon wrote:
TBH, I was surprised to see this on the table in the first place
myself...
To me the summary of events looks like:
1) People disagree whether goto is A Good Thing
2) PDM discusses it and settles for a compromise solution
No, we settled on an ini
Wez Furlong wrote:
Agreed; I see no reason to call it break (that makes it even more
confusing), and limiting jumps to one direction only is dumb; there is
no technical reason to do that.
Perl has a "goto" keyword, but it's pronounced "magic goto". We can
have a "goto" keyword and pronounce it
Christian Schneider wrote:
> 3) internals removes the restrictions of the compromise
Only one restriction is being removed, it being the ability to jump back
in the code.
> ?) It is added even though no clear majority wanted a full-blown goto
Last time goto was discussed it was a very close dec
Sara Golemon wrote:
TBH, I was surprised to see this on the table in the first place myself...
To me the summary of events looks like:
1) People disagree whether goto is A Good Thing
2) PDM discusses it and settles for a compromise solution
3) internals removes the restrictions of the compromis
working on a couple of PEAR packages, pear/Validate_UK and pear/HTML_AJAX.
Pierre (cvs user: pajoye) will sort out the karma
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Peter Brodersen wrote:
On Tue, 22 Nov 2005 18:57:19 +0100 (CET), in php.internals
[EMAIL PROTECTED] (Derick Rethans) wrote:
On 11 and 12 November a bunch of us had a developers meeting in Paris,
discussing the things we want to do for PHP 6. Partly because of the
Unicode support, but we also d
On Tue, 22 Nov 2005 18:57:19 +0100 (CET), in php.internals
[EMAIL PROTECTED] (Derick Rethans) wrote:
>On 11 and 12 November a bunch of us had a developers meeting in Paris,
>discussing the things we want to do for PHP 6. Partly because of the
>Unicode support, but we also discussed the items on
So, I'm +1 on the patch with sane names and removed restrictions;
Agreed.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Wez Furlong wrote:
> Perl has a "goto" keyword, but it's pronounced "magic goto". We can
> have a "goto" keyword and pronounce it "limited goto".
If goto has bad connotations for many people and break seems confusing,
how about calling it "jmp" or "jump" which precisely what the code does.
Ilia
1) The new syntax makes mess for me.
2) After (1) I don't see any reason in limitation to jump only down,
Both of these items were based on the PDM meeting notes which required this
specific behavior.
2) Your patch doesn't care about freeing loop variables
and we got a memory leaks in the fol
Agreed; I see no reason to call it break (that makes it even more
confusing), and limiting jumps to one direction only is dumb; there is
no technical reason to do that.
Perl has a "goto" keyword, but it's pronounced "magic goto". We can
have a "goto" keyword and pronounce it "limited goto".
Bad
Jani Taskinen schrieb:
> Wasn't there some talk about this not being very good idea?
> Anyway, adding stuff like this in a bugfix release is not
> something I'd allow right now..
The patch has been reviewed by Dmitry et al. and approved for PHP 5.1.1
by Ilia.
--
Sebastian Bergmann
Excellent work Dmitry. Hope your version of the patch gets accepted.
Well just go ahead and commit it :)
Edin
Dmitry Stogov wrote:
> Yes, we discussed.
> But I wasn't agree with "goto" at all.
> Now after looking in the patch, I see that limited "goto" can work.
>
> I still don't like "goto", b
Ilia Alshanetsky wrote:
> Derick Rethans wrote:
>
>
>>- we wanted to prevent spagetti code which you can do by jumping up:
>>
>> "Similarly restricting the construct so that you can only jump
>> down should satisfy people who do not want the ability to jump all over
>> the place.
Derick Rethans wrote:
> - we wanted to prevent spagetti code which you can do by jumping up:
>
> "Similarly restricting the construct so that you can only jump
> down should satisfy people who do not want the ability to jump all over
> the place."
IMO making this limitation p
On Thu, 24 Nov 2005, Matthias Pigulla wrote:
Admittedly this is ugly to read but the same thing on the other side is
$var[$x][$y] vs. $var[$x]{$y}.
True. But having two purposes for {} is not good either.
And most of the time it's up to the coders how they use the existing
features
Yes, we discussed.
But I wasn't agree with "goto" at all.
Now after looking in the patch, I see that limited "goto" can work.
I still don't like "goto", but reusing name "break" for "goto" is mach
worst.
The following code works fine with Sara's patch:
BTW: some languages has "break label" ope
One more thing.
The patch has problems with "interactve mode" (php -a).
Thanks. Dmitry.
> -Original Message-
> From: Dmitry Stogov [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 24, 2005 12:54 PM
> To: 'Sara Golemon'; internals@lists.php.net
> Cc: Andi Gutmans; Zeev Suraski; Stani
On Thu, 24 Nov 2005, Dmitry Stogov wrote:
> 1) The new syntax makes mess for me.
> "break" is a statement that exits from loop or switch, now we make a "goto"
> statement but name it "break".
> I belive that if we really implement goto (even with some limitations) we
> shuld name it "goto", but no
Hi Sara,
I didn't like "goto" in PHP, but after looking in this patch I see that
limited "goto" can work.
1) The new syntax makes mess for me.
"break" is a statement that exits from loop or switch, now we make a "goto"
statement but name it "break".
I belive that if we really implement goto (even
> -Ursprüngliche Nachricht-
> Von: Jani Taskinen [mailto:[EMAIL PROTECTED]
> We could start with making it an E_ERR..erm..E_STRICT notice
> if you use {} with arrays or [] with strings. And really separate
> them in PHP 6. But does it make any sense?
At least some people
On Thu, 24 Nov 2005, Jakub Vrana wrote:
4.5 Cleanup for {} vs. []
It was already discussed. Many people would be confused from
documentation statement "[] was marked as deprecated in 4.0.6 - 5.1
but then suddenly {} was deprecated instead and removed in 6.0" and
many scripts would refuse to wo
50 matches
Mail list logo
