Yes, but if you're not planning to have any module globals,
wouldn't it be better to just nuke the lines?
--Jani
On Fri, 18 Nov 2005, Marcus Boerger wrote:
Hello Rob,
we can define a dummy in it. I thought that some compilter don't like
empty structs.
marcus
Friday, November
Just a friendly note from my PHP user side:
We had 2 places where {} where used for accessing string.
Took me 10 seconds to remove those with the help of
the nice E_STRICT error. (filename, linenumber)
--Jani
On Thu, 17 Nov 2005, Rasmus Lerdorf wrote:
Andreas Korthaus w
Hello Rob,
we can define a dummy in it. I thought that some compilter don't like
empty structs.
marcus
Friday, November 18, 2005, 4:18:51 AM, you wrote:
> Marcus,
> are you going to be using any module globals in the extension?
> I had to remove the code for it to get it to build on windows
Hi Steph,
Maybe in section 4, explain what the result of the change is. You explain
what was wrong in the past, but don't really cover what the new behavior is.
Bob
> -Original Message-
> From: Steph Fox [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 17, 2005 9:11 PM
> To: internal
I know it's 50-50 at least one of these items will change before my mail
reaches the list, but here's version 4 for your perusal.
Note: I have type hints for arrays down as being 'still under discussion' -
this isn't actually ready to go.
I've thrown out new features such as the Zend VM execution
Todd Ruth wrote:
> The hope
> in my original email is that if php is clever enough to give
> me a message, it might be clever enough to just make the change
> too.
A scripting language is not a spell checker, you can forget about it
auto-correcting your code. The E_STRICT/E_NOTICE messages are emi
Hi Andrei!
Andrei Zmievski wrote:
You will break many more scripts by dropping [] for strings than the
other way around. Do you agree?
Until tonight I was sure that only a few projects still use the []
syntax which is depreciated for 5 years.
But if some of you don't think so I'm probably wr
Marcus,
are you going to be using any module globals in the extension?
I had to remove the code for it to get it to build on windows - patached
attached.
Though it does build fine if you do define some.
Rob
Index: php_reflection.c
==
You will break many more scripts by dropping [] for strings than the
other way around. Do you agree?
-Andrei
On Nov 17, 2005, at 3:26 PM, Andreas Korthaus wrote:
OK, but by dropping {} for strings you also remove the possibility
to have a convention like "[] for arrays and {} for strings".
How do you know this? Have you conducted polls?
-Andrei
On Nov 17, 2005, at 3:19 PM, Jevon Wright wrote:
Is there anything wrong with having a convention for character
access of strings? Most PHP programmers see {} as string access and
[] as array access - sure, they might be functionally
On Thu, 2005-11-17 at 16:47 -0800, Rasmus Lerdorf wrote:
> Todd Ruth wrote:
...
> > It would be so wonderful to throw all my code at a tool that would
> > change everything that can be easily changed and give me a list of
> > spots I need to look at manually. A lot of the changes don't take
> > an
Hi Todd,
I'm hoping that in future we can provide better tools for upgrading
in between versions. Both from an auto-conversion perspective and
just scanning the code statically and printing out warnings on what
code to check. Coupled with better upgrading docs I think we'd
improve the current
Todd Ruth wrote:
I'd been ignoring the "curly braces" thread, but then I grepped my
code and ... sure enough, I have curly braces that are used to index
into strings. I don't care about this philosophically, but it makes
me wonder about upgrade tools. I know I shouldn't ask this without
volunte
I'd been ignoring the "curly braces" thread, but then I grepped my
code and ... sure enough, I have curly braces that are used to index
into strings. I don't care about this philosophically, but it makes
me wonder about upgrade tools. I know I shouldn't ask this without
volunteering to do it myse
Rasmus Lerdorf wrote:
And you are willing to break just about every application out there for
this?
I didn't know how many applications use [] with strings. I only know a
lot of applications using {}. The point is not "breaking existing apps",
but destroy a sensable convention, which is us
On Thu, 2005-11-17 at 19:05, Rasmus Lerdorf wrote:
> Robert Cummings wrote:
> > On Thu, 2005-11-17 at 18:33, Ilia Alshanetsky wrote:
> >> Andreas Korthaus wrote:
> >>> OK, but by dropping {} for strings you also remove the possibility to
> >>> have a convention like "[] for arrays and {} for string
Robert Cummings wrote:
On Thu, 2005-11-17 at 18:33, Ilia Alshanetsky wrote:
Andreas Korthaus wrote:
OK, but by dropping {} for strings you also remove the possibility to
have a convention like "[] for arrays and {} for strings".
If I could decide I would drop {} for arrays and [] for strings, b
On Thu, 2005-11-17 at 18:51, Robert Cummings wrote:
> On Thu, 2005-11-17 at 18:33, Ilia Alshanetsky wrote:
> > Andreas Korthaus wrote:
> > > OK, but by dropping {} for strings you also remove the possibility to
> > > have a convention like "[] for arrays and {} for strings".
> > > If I could decide
On Thu, 2005-11-17 at 18:33, Ilia Alshanetsky wrote:
> Andreas Korthaus wrote:
> > OK, but by dropping {} for strings you also remove the possibility to
> > have a convention like "[] for arrays and {} for strings".
> > If I could decide I would drop {} for arrays and [] for strings, but I
> > fear
Once more unto the breach.
One of the issues that was open until now was a regression in the
behavior of Apache 2 sapi on non-linux systems. The problem was finally
discovered and resolved, so if you've experienced crashes or "weird"
behavior with Apache 2 and PHP 5.1/4.4.1, please give this RC a
Andreas Korthaus wrote:
> OK, but by dropping {} for strings you also remove the possibility to
> have a convention like "[] for arrays and {} for strings".
> If I could decide I would drop {} for arrays and [] for strings, but I
> fear I will not be asked to decide... ;-)
You may think that {} an
Andreas Korthaus wrote:
OK, but by dropping {} for strings you also remove the possibility to
have a convention like "[] for arrays and {} for strings".
If I could decide I would drop {} for arrays and [] for strings, but I
fear I will not be asked to decide... ;-)
And you are willing to break
Rasmus Lerdorf wrote:
Andreas Korthaus wrote:
But you know without understanding of any context, that it's the 6th
character of the string "$str". When you see $var[5], it could be the
6th character of a string, or an element of an array... and what
about the value? You can't be sure that it's
Is there anything wrong with having a convention for character access of
strings? Most PHP programmers see {} as string access and [] as array access -
sure, they might be functionally identical, but its the convention which is
important.
Jevon
> ---Original Message---
> From: Rasmu
Andreas Korthaus wrote:
As far a code readability and obviousness goes, I doubt anybody would
guess their way to the $str{5} syntax.
But you know without understanding of any context, that it's the 6th
character of the string "$str". When you see $var[5], it could be the
6th character of a st
Hi Rasmus!
Rasmus Lerdorf wrote:
Very few people converted to using {} so the argument about reading old
code doesn't really hold.
I can't belive that most of the code today is based on <=PHP3 code. I'm
not talking about such "PHP3 based" code. I'm talking about code, you
wrote 1 year ago
On Thu, 2005-11-17 at 16:42, Rasmus Lerdorf wrote:
> Andreas Korthaus wrote:
>
> > Can someone tell me the reason for this decision?
>
> Very few people converted to using {} so the argument about reading old
Ugh, so those of us that did are going to have to comb back through our
code and rever
Rasmus Lerdorf wrote:
Very few people converted to using {} so the argument about reading old
code doesn't really hold. If you go and grep through all the public
code out there, pretty much none of it uses {} for character offsets.
I'd like to cite Andi here:
"Regarding BC breakage. I'm not
Andreas Korthaus wrote:
Can someone tell me the reason for this decision?
Very few people converted to using {} so the argument about reading old
code doesn't really hold. If you go and grep through all the public
code out there, pretty much none of it uses {} for character offsets.
And in
Hi!
Ilia Alshanetsky wrote:
Once again, I encourage everyone to take the time to try out this RC and
test it against your code or simply run "make test".
Works fine for me, but I've a question about the dropped curly braces.
Has there been some public discussion about it recently? I'm sorry if
Ilia Alshanetsky wrote:
You cannot give it
an md5 and have it generate you a string with the same md5 hash, so md5
is still relatively safe.
http://www.google.com/search?q=md5+hash+lookup&start=0&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official
--
PHP Internals - PHP
Jacques Marneweck wrote:
Are there any chances of getting this implemented in the next releases
of PHP 5.0.X and 4.4.X?
I don't think there will be any further 5.0.x release.
Sebastian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Roman,
I was in the same spot 2 weeks ago. Having never programmed in C before and
knowing nothing about PHP internals I wasn't sure where to start. The
documentation has an appendix in it that covers PHP4 Zend API but a lot is
still relevant (or close enough) to begin. Make use of the skeleton
Sean Coates wrote:
> FYI,
>
> I just turned on inventory control for products 89-93, and gave them
> 1 units each (this is to make the backend send me mail on signup).
>
Sorry.
Wrong list. My apologies.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
FYI,
I just turned on inventory control for products 89-93, and gave them
1 units each (this is to make the backend send me mail on signup).
--
Sean Coates
(php|architect)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I understood you. You don't test 5.1 -> then there is not problem with it.
5.1 is the next release. Not 5.0.x.
--Jani
On Thu, 17 Nov 2005, Michael Sisolak wrote:
Jani,
Sorry I wasn't clear - I'm running 5.0.5 in development also. There is
something that happens with 5.0.5 + ph
Jani,
Sorry I wasn't clear - I'm running 5.0.5 in development also. There is
something that happens with 5.0.5 + php_admin_value (or at least my
specific one) in production that I can't reproduce on another 5.0.5
machine. I assume it has to do with me not being able to accurately
reproduce the l
Then there is no problem. Next please. :)
--Jani
On Thu, 17 Nov 2005, Michael Sisolak wrote:
Jani,
Unfortunately I can't get this to reproduce in my development
environment and it's too early for me to switch to 5.1 in production.
Michael
--- Jani Taskinen <[EMAIL PROTECTED]> w
Jani,
Unfortunately I can't get this to reproduce in my development
environment and it's too early for me to switch to 5.1 in production.
Michael
--- Jani Taskinen <[EMAIL PROTECTED]> wrote:
>
> Do you hit the same issue with using the latest PHP 5.1
> snapshot?
>
> --Jani
>
> On W
I'd say if anybody should know this for certain, it's somebody who
bothers to benchmark it:
$ time php -r '$s="abc";for($i=0;$i<1000;++$i);'
real0m1.966s
user0m1.634s
sys 0m0.072s
$ time php -r '$s="abc";for($i=0;$i<1000;++$i) $s=="abc";'
real0m3.974s
user0m3.779s
Hello Roman,
http://talks.somabo.de and in general try the source lurke :-)
marcus
Thursday, November 17, 2005, 9:47:28 AM, you wrote:
> I've read two tutorials from Sara Golemon
> (http://zend.com/php/internals/), but it's not enought for me to start
> writing a real extension. Are there a
If anybody should know this for certain, it's core developers, hence my
question here. I'm curious if type certainty requires an extra check, or a
check less.
Which of these is faster?
if ($str === 'abc') { }
if ($str == 'abc') { }
I expect the triple '=' to be faster, but I'd like to be sure.
42 matches
Mail list logo
