The behavior in 5.3 is actually more correct then in 5.2. In 5.3 we
only skip # on the first line if it is followed by ! indicating its an
instruction to execute some binary. In 5.2 on the other hand 1st line
starting with # is skipped, which is not entirely correct.
Ilia Alshanetsky
O
CLI
-Hannes
On Sun, Apr 19, 2009 at 18:21, Ilia Alshanetsky wrote:
> Are you using CGI or CLI sapi?
>
> Ilia Alshanetsky
>
>
>
>
> On 19-Apr-09, at 12:16 PM, Hannes Magnusson wrote:
>
>> I'm pretty sure yes.
>> Try copying the run-tests.php from 5_2 to 5_3 and run the PDO tests with
>> it.
>> Th
Are you using CGI or CLI sapi?
Ilia Alshanetsky
On 19-Apr-09, at 12:16 PM, Hannes Magnusson wrote:
I'm pretty sure yes.
Try copying the run-tests.php from 5_2 to 5_3 and run the PDO tests
with it.
Then diff the run-tests to see the workaround in 5.3.
-Hannes
On Sun, Apr 19, 2009 at 17:
I'm pretty sure yes.
Try copying the run-tests.php from 5_2 to 5_3 and run the PDO tests with it.
Then diff the run-tests to see the workaround in 5.3.
-Hannes
On Sun, Apr 19, 2009 at 17:57, Ilia Alshanetsky wrote:
> Last I checked it was working properly, are you sure you are using the
> latest
Last I checked it was working properly, are you sure you are using the
latest version? I think we even have a test case around this bug.
Ilia Alshanetsky
On 19-Apr-09, at 7:09 AM, Hannes Magnusson wrote:
On Sat, Apr 18, 2009 at 23:48, Nuno Lopes wrote:
The original code actually can be
On Sat, Apr 18, 2009 at 23:48, Nuno Lopes wrote:
The original code actually can be found inside php_cli.c and there it
only checked the 1st line for '#'. if you create a file such as:
#1
#2
>>
>>> The issue here is that the old code only looked at the main script, now
>>>
The original code actually can be found inside php_cli.c and there it
only checked the 1st line for '#'. if you create a file such as:
#1
#2
The issue here is that the old code only looked at the main script, now
included files ar affected, too.
So either we check in the scanner whether this is
Hello Etienne,
Friday, August 8, 2008, 9:54:49 PM, you wrote:
> Hello,
> On Fri, Aug 8, 2008 at 9:50 PM, Etienne Kneuss <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> On Fri, Aug 8, 2008 at 7:10 PM, Marcus Boerger <[EMAIL PROTECTED]> wrote:
>>> helly Fri Aug 8 17:10:49 2008 UTC
>>>
>>> M
On Fri, Aug 8, 2008 at 21:54, Etienne Kneuss <[EMAIL PROTECTED]> wrote:
> Forgot to mention it: there is something weird in mysqli_driver.c, I
> don't know what the author's original intention was, but it looks
> wrong.
> c.f. FIXME
I think I already filed a bug report about that some months ago,
Hello Lukas,
Sunday, July 27, 2008, 12:00:55 PM, you wrote:
> On 27.07.2008, at 02:58, Marcus Boerger wrote:
>> Hello Internals,
>>
>> apparently overloaded objects do not need to implement property
>> access
>> and we issue an E_NOTICE in case someone tries to none-the-less.
>> Dmirty
>>
On 27.07.2008, at 02:58, Marcus Boerger wrote:
Hello Internals,
apparently overloaded objects do not need to implement property
access
and we issue an E_NOTICE in case someone tries to none-the-less.
Dmirty
thankfully made this consistent for all handlers now. However this
raised a
ques
Marcus Boerger escribió:
Hello Internals,
apparently overloaded objects do not need to implement property access
and we issue an E_NOTICE in case someone tries to none-the-less. Dmirty
thankfully made this consistent for all handlers now. However this raised a
question on my side, whether we s
Hello Stanislav,
I must be having a headache here. But there seriously seems to be a
misunderstanding.
We definitively introduced __construct as a bug fix in our language design.
And that is that you can have a function a in your class b that suddenly
becomes a constructor in the derived class
On 5/5/08, Pierre Joye <[EMAIL PROTECTED]> wrote:
> We can then even drop the old form in php 6.x. Many changes have no
> gain but make the language clearer or cleaner. It is not an objective
> change but it does help to cleanup the language.
>
> I will not die if we still support old things fo
On Mon, May 5, 2008 at 9:18 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
>
>
> > kind of stuff is quite easy to fix. Throw a deprecated warning in 5.3 and
> remove in PHP 6.x.
> >
>
> There's nothing to fix, it's not broken.
Ok, point made. Once again a "you vs all other" thread, no
Hi!
kind of stuff is quite easy to fix. Throw a deprecated warning in 5.3
and remove in PHP 6.x.
There's nothing to fix, it's not broken.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runti
Hi!
We can then even drop the old form in php 6.x. Many changes have no
gain but make the language clearer or cleaner. It is not an objective
change but it does help to cleanup the language.
There's nothing to "cleanup". You trying to prove that this form should
be removed by representing it
On 05.05.2008, at 20:51, Pierre Joye wrote:
On Mon, May 5, 2008 at 8:43 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
It's just simple to make constructors work in the same way in
namespaces and
out of them. It would be difficult to explain why the first script
prints
"ok" and the second do
Hi!
As it can't break any code out there, I would like to do not support
the old style constructors in namespace (cleanup++).
Right, this is not needed at all.
If by old-style ctors you mean this:
namespace Foo;
class Bar {
function Bar() {/* ctor! */}
}
then I think it should be su
Pierre Joye escribió:
As it can't break any code out there, I would like to do not support
the old style constructors in namespace (cleanup++).
Right, this is not needed at all.
--
"Progress is possible only if we train ourselves to think about programs
without thinking of them as pieces o
Thanks Dmitry!
- Original Message -
From: "Dmitry Stogov" <[EMAIL PROTECTED]>
To: "Steph Fox" <[EMAIL PROTECTED]>
Cc: "internals"
Sent: Wednesday, March 12, 2008 8:54 AM
Subject: [PHP-DEV] RE: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) /
zend_API.c zend_builtin_functions.c zend_compi
On Tue, 12 Feb 2008, Andi Gutmans wrote:
> It's really hard to remember this stuff.
> Maybe we should make the system actually validate the messages when they
> are committed and reject the commit when tags are missing. For commits
> where a certain tag isn't relevant we could have an explicit way
t that way it's in the back (and front) of
people's mind :)
Andi
> -Original Message-
> From: Jani Taskinen [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 12, 2008 10:31 AM
> To: Hannes Magnusson
> Cc: PHP Development
> Subject: Re: [PHP-DEV] Re: [ZEN
On Feb 12, 2008 7:47 PM, Hannes Magnusson <[EMAIL PROTECTED]> wrote:
> On Feb 12, 2008 7:35 PM, Pierre Joye <[EMAIL PROTECTED]> wrote:
> > On Feb 12, 2008 7:31 PM, Jani Taskinen <[EMAIL PROTECTED]> wrote:
> > >
> > > I myself have forgot to use the damn dog tag many times. (Which is it
> > > again,
On Feb 12, 2008 7:35 PM, Pierre Joye <[EMAIL PROTECTED]> wrote:
> On Feb 12, 2008 7:31 PM, Jani Taskinen <[EMAIL PROTECTED]> wrote:
> >
> > I myself have forgot to use the damn dog tag many times. (Which is it
> > again, @DOC@ or [DOC] ? :) And if I forget, I'd like to be reminded.
>
> Same here, I
On Feb 12, 2008 7:31 PM, Jani Taskinen <[EMAIL PROTECTED]> wrote:
> Please, when you give such feedback, please point finger at the persons
> who deserve it. Now it feels like everyone is "misbehaving" here.
> Not only mention the name in the body of the email but Cc: the mail to
> these people. Ea
Please, when you give such feedback, please point finger at the persons
who deserve it. Now it feels like everyone is "misbehaving" here.
Not only mention the name in the body of the email but Cc: the mail to
these people. Each and everyone who deserves to get spanked. And I'm not
joking..
I mysel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 5, 2007, at 08:06:20, Jani Taskinen wrote:
Sorry for the top posting Derick. :)
Stas, this patch solves the problems with @ and doing
"php_admin_value error_reporting ":
http://pecl.php.net/~jani/patches/zend_alter_ini_entry.patch
Very n
That would be a solution. The only thing is that this would be a break in BC
for extensions using zend_alter_ini_entry.
I will test your patch with my webserver together with the @-Operator.
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
> -Or
lead to big discussions (well, as some "random" revert might
too...)
johannes
>
> Andi
>
>
> > -Original Message-
> > From: Hannes Magnusson [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, August 14, 2007 12:31 AM
> > To: Stas Malyshev
day, August 14, 2007 12:31 AM
> > To: Stas Malyshev
> > Cc: internals@lists.php.net
> > Subject: Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2)
> > / zend_language_parser.y
> >
> > On 8/14/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> >
ot a screw you... And the patch will go in
right after 5.2.4.
Andi
> -Original Message-
> From: Hannes Magnusson [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 14, 2007 12:31 AM
> To: Stas Malyshev
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: [ZEND-
Hannes Magnusson wrote:
On 8/14/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
A Major bugfix maybe ( yes, it was clearly a bug/misfeature)
A bug is when code doesn't do what was intended. This is not the case,
this is the case of missing feature. While I think everybody agrees this
featur
On 8/14/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > A Major bugfix maybe ( yes, it was clearly a bug/misfeature)
>
> A bug is when code doesn't do what was intended. This is not the case,
> this is the case of missing feature. While I think everybody agrees this
> feature is good to us,
A Major bugfix maybe ( yes, it was clearly a bug/misfeature)
A bug is when code doesn't do what was intended. This is not the case,
this is the case of missing feature. While I think everybody agrees this
feature is good to us, it's not the time to add it. We lived for years
without it, we c
On 8/13/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > Was there something wrong with the patch or what?
>
> Yes, it was major syntax change in minor version.
A Major bugfix maybe ( yes, it was clearly a bug/misfeature)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscri
Then this needs to be clear in the NEWS file as this is in RC1...
-Hannes
On 8/14/07, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> Jani,
>
> Dmitry asked that the patch be reverted and I agreed with him. Since
> the author didn't have time (I am guessing), I've asked Stas to
> revert the patch.
Jani,
Dmitry asked that the patch be reverted and I agreed with him. Since
the author didn't have time (I am guessing), I've asked Stas to
revert the patch. The reason being that this change is too major to
commit at the very last minute in the release cycle. The code will go
back into CV
On Fri, 3 Aug 2007, Stanislav Malyshev wrote:
> > I see that this feature will be backported to older PHP 5 and even to
> > PHP 4 used by linux/bsd distributions, because it is a required security
>
> BTW: I plan to merge it in 4.4 tree, but since there's no 4.4 release planned
> soon AFAIK I wan
Yes, I know.
My patch didn't remove "Fatal error" behavior, however may be it is
possible.
Dmitry.
> -Original Message-
> From: Hannes Magnusson [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 09, 2006 2:17 PM
> To: Dmitry Stogov
> Cc: internals@lists.php.net; Andi Gutmans; Ilia Als
On Mon, October 23, 2006 3:43 pm, Ilia Alshanetsky wrote:
>
> On 23-Oct-06, at 4:16 PM, Richard Lynch wrote:
>
>> Some ISPs will be quicker to upgrade LAMP than to let users build
>> SSH
>> tunnels.
>
> If your ISP does not give you SSH, perhaps it is time to find
> yourself another ISP.
I agree w
On 23-Oct-06, at 4:16 PM, Richard Lynch wrote:
Some ISPs will be quicker to upgrade LAMP than to let users build SSH
tunnels.
If your ISP does not give you SSH, perhaps it is time to find
yourself another ISP.
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To un
On Fri, October 20, 2006 9:26 am, Ilia Alshanetsky wrote:
>
> On 20-Oct-06, at 10:24 AM, Lukas Kahwe Smith wrote:
>
>> Ilia Alshanetsky wrote:
>>
its funny that ext/mysql is supposed to stay around for BC
reasons even in PHP6, yet it has known unsolvable security issues.
>>> Such as?
>>
>
On Fri, October 20, 2006 9:35 am, Ilia Alshanetsky wrote:
>
> On 20-Oct-06, at 10:29 AM, Edin Kadribasic wrote:
>> "Known OO conventions" -> how Java people do it
>> "Its supposed to work that way" -> it works like that in Java
>> ...
>
> Java is just a single OO language out of many, http://
> en.
Gregory Beaver wrote:
Hi Ilia and everyone,
E_DEPRECATED makes good sense - it can be a big warning flag that
something will be removed, and will make it very easy to code around
changes. Once something is E_DEPRECATED, however, it must stay that
way, I agree with Ilia.
The point of E_STRICT a
Hi Ilia and everyone,
E_DEPRECATED makes good sense - it can be a big warning flag that
something will be removed, and will make it very easy to code around
changes. Once something is E_DEPRECATED, however, it must stay that
way, I agree with Ilia.
The point of E_STRICT as originally stated was
Adding more error modes is fine and dandy, but it has to be with a
good reason in mind. In my mind if we add E_DEPRECATED and mark
certain behavior as deprecated it means in a certain version, PHP6
(for example) it will go away and no longer work. Marking something
as deprecated with no int
Marcus Boerger wrote:
That said I can only repeat here what I said earlier on IRC. Lets do things
right and make the more complex OO rules as E_STRICT and create new severity
level E_DEPRECATED. E_STRICT will then only be used for 'pedantic' OO rules
while E_DEPRECATED will be used for stuff tha
Hello William,
Saturday, October 21, 2006, 1:04:44 AM, you wrote:
> Ilia Alshanetsky wrote:
>>
>> On 20-Oct-06, at 5:10 PM, Marcus Boerger wrote:
>>
>>> Hello Ilia,
>>>
>>> also an ISO/shared server will never be securewhatever you do and
>>> you can
>>> make MySQL disaalow external connectio
Ilia Alshanetsky wrote:
>
> On 20-Oct-06, at 5:10 PM, Marcus Boerger wrote:
>
>> Hello Ilia,
>>
>> also an ISO/shared server will never be securewhatever you do and
>> you can
>> make MySQL disaalow external connections. That basically means in those
>> scenarios you do not need any authenticat
On 10/20/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
One question I like to give to everyonedropping rules out of PHP. If you
want OO without rules, why do you use inheritance after all? Ever considered
OO might be the wrong programming paradigm for you :-)
It's not so much that "we" want OO
On 20-Oct-06, at 5:10 PM, Marcus Boerger wrote:
Hello Ilia,
also an ISO/shared server will never be securewhatever you do and
you can
make MySQL disaalow external connections. That basically means in
those
scenarios you do not need any authentication at all and thus get
better
speed a
On Fri, 2006-10-20 at 23:05 +0200, Marcus Boerger wrote:
> Hello Lukas,
>
> nonsense, there was no OO in PHP 4. We only had arrays with somehow
I think you're leaning too much on a specific definition of OO that
isn't necessarily shared by the rest of the cosmos, especially the
millions of PHP4
Hello Ilia,
also an ISO/shared server will never be securewhatever you do and you can
make MySQL disaalow external connections. That basically means in those
scenarios you do not need any authentication at all and thus get better
speed as in more responses. Now is that bad?
best regards
marcus
Hello Lukas,
nonsense, there was no OO in PHP 4. We only had arrays with somehow
attached methods. No static, no abstract, no visibiity, no nothing. Then PHP
5.0 was done in a very bad rush and we made mistakes as we didn'T have time
to test it. Thus we had to quickly deliver 5.1. And even 5.1 i
On 20/10/06, Edin Kadribasic <[EMAIL PROTECTED]> wrote:
Lukas Kahwe Smith wrote:
> Ilia Alshanetsky wrote:
>
>> It is working code, its far from perfect given that it makes little
>> programatic sense and does break all known OO conventions.
>
> Being allowed to break these "known OO conventions"
On 20-Oct-06, at 10:29 AM, Edin Kadribasic wrote:
"Known OO conventions" -> how Java people do it
"Its supposed to work that way" -> it works like that in Java
...
Java is just a single OO language out of many, http://
en.wikipedia.org/wiki/Object-oriented_programming_language (here is a
ni
On 20-Oct-06, at 10:26 AM, Lukas Kahwe Smith wrote:
Ilia Alshanetsky wrote:
It is working code, its far from perfect given that it makes
little programatic sense and does break all known OO conventions.
Being allowed to break these "known OO conventions" is a major
feature, which has esta
Lukas Kahwe Smith wrote:
> Ilia Alshanetsky wrote:
>
>> It is working code, its far from perfect given that it makes little
>> programatic sense and does break all known OO conventions.
>
> Being allowed to break these "known OO conventions" is a major
> feature, which has established PHP as a rapi
Ilia Alshanetsky wrote:
It is working code, its far from perfect given that it makes little
programatic sense and does break all known OO conventions.
Being allowed to break these "known OO conventions" is a major feature,
which has established PHP as a rapid prototyping language. Having some
On 20-Oct-06, at 10:24 AM, Lukas Kahwe Smith wrote:
Ilia Alshanetsky wrote:
its funny that ext/mysql is supposed to stay around for BC
reasons even in PHP6, yet it has known unsolvable security issues.
Such as?
for example, it does not support the new more secure authentication
protocol
Ilia Alshanetsky wrote:
its funny that ext/mysql is supposed to stay around for BC reasons
even in PHP6, yet it has known unsolvable security issues.
Such as?
for example, it does not support the new more secure authentication
protocol.
regards,
Lukas
--
PHP Internals - PHP Runtime Devel
On 20-Oct-06, at 4:58 AM, Lukas Kahwe Smith wrote:
Edin Kadribasic wrote:
I'm sure there are more examples of how PHP 5.2 and newer will
enforce a
different "spirit" that smells more off a static programming
language.
and these changes are being made in a minor release!
Minor releases
Edin Kadribasic wrote:
I'm sure there are more examples of how PHP 5.2 and newer will enforce a
different "spirit" that smells more off a static programming language.
and these changes are being made in a minor release!
its funny that ext/mysql is supposed to stay around for BC reasons even
Andi Gutmans wrote:
> Seems like I missed that whole thread.
> I don't quite understand what we have to gain from dissallowing overriding
> static methods and/or abstract static methods. It's not really in the PHP
> spirit.
> Making it E_STRICT doesn't solve the situation because it will tell peopl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
The reason 'abstract static' makes no sense is because static methods
are bound to the class they are defined in. Inheritance rules do not apply.
Therefore a static method that is defined abstract would theoretically
never be able to be implemented.
Interesting.
http://icu.sourceforge.net/apiref/icu4c/
uclean_8h.html#93f27d0ddc7c196a1da864763f2d8920
Perhaps we should not call u_cleanup() at all..
-Andrei
On Oct 4, 2006, at 1:42 PM, Rob Richards wrote:
That does prevent the crash.
I did find that within zend_shutdown, if I comment out
That does prevent the crash.
I did find that within zend_shutdown, if I comment out the call to
u_cleanup(), then ucol_close doesn't crash within unicode_globals_dtor
during tsrm_shutdown.
If that helps any.
Rob
Andrei Zmievski wrote:
I suppose we can omit the ucol_close() call since we're s
I suppose we can omit the ucol_close() call since we're shutting down
completely and ICU will close all resources anyway on exit, I believe.
-Andrei
On Oct 4, 2006, at 6:28 AM, Rob Richards wrote:
Seems to be a windows only problem for me. Works fine under linux, but
I've tried 3 different
Seems to be a windows only problem for me. Works fine under linux, but
I've tried 3 different builds of the ICU library - even built one from
source - and it always crashes at the same point within the ucol_close call.
Rob
Andrei Zmievski wrote:
Strange. I don't see it here on FreeBSD. Does an
Seems a little excessive to me!
On 18/07/06, Andrei Zmievski <[EMAIL PROTECTED]> wrote:
I just realized that it's the first time I used a quadruple pointer.
Must celebrate.
-Andrei
On Jul 18, 2006, at 3:07 PM, Andrei Zmievski wrote:
> + zval varargs = NULL;
> + int *n_varargs = N
Hello Andrei,
oh my godlet's have a few beers on that during oscon at the oregon
brewers festival :-)
best regards
marcus
Wednesday, July 19, 2006, 12:16:22 AM, you wrote:
> I just realized that it's the first time I used a quadruple pointer.
> Must celebrate.
> -Andrei
> On Jul 18,
Sure. Starts on Thursday.
-A
On Jul 18, 2006, at 3:54 PM, Marcus Boerger wrote:
Hello Andrei,
oh my godlet's have a few beers on that during oscon at the
oregon
brewers festival :-)
best regards
marcus
Wednesday, July 19, 2006, 12:16:22 AM, you wrote:
I just realized that it's t
On Tue, April 18, 2006 1:11 pm, Pierre wrote:
> On 4/18/06, Andrei Zmievski <[EMAIL PROTECTED]> wrote:
>> Once again, people who upgrade to PHP 6 will either turn the unicode
>> switch and stick with it (in which case they will see "binary
>> string"
>> and "Unicode string") or they will keep the s
On Tue, 18 Apr 2006, Pierre wrote:
> On 4/18/06, Andrei Zmievski <[EMAIL PROTECTED]> wrote:
> > Once again, people who upgrade to PHP 6 will either turn the unicode
> > switch and stick with it (in which case they will see "binary string"
> > and "Unicode string") or they will keep the switch off
On 4/18/06, Andrei Zmievski <[EMAIL PROTECTED]> wrote:
> Once again, people who upgrade to PHP 6 will either turn the unicode
> switch and stick with it (in which case they will see "binary string"
> and "Unicode string") or they will keep the switch off (and will live
> merrily thereafter with "st
Once again, people who upgrade to PHP 6 will either turn the unicode
switch and stick with it (in which case they will see "binary string"
and "Unicode string") or they will keep the switch off (and will live
merrily thereafter with "string"). They won't be flipping back and
forth.
-Andrei
O
On 4/18/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Yeah I agree. OK I guess we can keep it like this.
Can we keep only "string" then? "string in non-unicode behaves exactly
like "binary string" in unicode mode.
--Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, v
Yeah I agree. OK I guess we can keep it like this.
At 10:32 AM 4/18/2006, Andrei Zmievski wrote:
I think this is a minor issue in any case, but consider this. Most
of the people who will upgrade from PHP 5 to 6 will not touch
unicode_semantics switch and it will default to Off. And then all of
I think this is a minor issue in any case, but consider this. Most of
the people who will upgrade from PHP 5 to 6 will not touch
unicode_semantics switch and it will default to Off. And then all of a
sudden they are getting messages about "binary string". I think that is
more confusing.. Especi
On 18.04.2006 21:24, Pierre wrote:
On Tue, 18 Apr 2006 10:15:42 -0700
[EMAIL PROTECTED] (Andi Gutmans) wrote:
Do we really need this? I'd prefer to keep "string" and "unicode"
I was asking the same thing. We should have only two names, as we have
actually only two types, binary and unicode.
On 3/10/06, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> Guys,
>
> If you like "goto" instead of "jump", please open yet another vote.
> I am indifferent with name.
Why vote again? Your original call was using "goto"... anyway +1 for"goto"
--Pierre
--
PHP Internals - PHP Runtime Development Mailin
> If you like "goto" instead of "jump", please open yet another vote.
> I am indifferent with name.
Let's call it goto.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
gt; Cc: PHP Developers Mailing List
> Subject: Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2
> / zend_compile.czend_compile.h zend_execute_API.c
> zend_globals.h zend_language_parser.y
> zend_language_scanner.lzend_opcode.c zend_vm_def.h
> zend_vm_execute.h zend_vm_opcodes.h
Derick Rethans wrote:
> On Fri, 10 Mar 2006, Dmitry Stogov wrote:
>
>
>> Log:
>> Implemented "jump label" operator (limited "goto")
>
>
> I don't think we decided on the name "jump" actually. I would really
> recommend to call this "goto" as that what it is and what people expect
> it to be
Don't worry, we follow the cvs lists.
I'll document it as soon as the code stabilizes.
Nuno
- Original Message -
Thanks for your help Sara!
Any chance someone from the Doc project has time to update the manual?
Thanks.
Andi
At 05:09 AM 3/3/2006, Dmitry Stogov wrote:
dmitry
Hello Mike,
right, but those are considerations one has to do with any member of an
interface.
best regards
marcus
Monday, March 6, 2006, 8:23:36 PM, you wrote:
> I am guessing he is referring to the fact that it becomes increasingly
> likely that you will have more interfaces declaring __con
I am guessing he is referring to the fact that it becomes increasingly
likely that you will have more interfaces declaring __construct. If any
two interfaces declare construct with a different signature then by
definition those two interfaces will be incompatible.
It just means that interface auth
Hello l0t3k,
there is nothing new here besides that fact that now you can also have a
method with the name '__construct' in an interface. Nothing else changed.
marcus
Monday, March 6, 2006, 1:42:50 PM, you wrote:
> This should cause much fun with classes implementing multiple interfaces
On Feb 27, 2006, at 12:49 PM, Mike Naberezny wrote:
The code below echoes "it works" on PHP_5_1 and HEAD but raises a
notice on the other branches.
excellent! It seems this can be closed then?
http://bugs.php.net/bug.php?id=29070
Regards,
Jeff
--
PHP Internals - PHP Runtime Development M
Hello Derick,
Tuesday, November 15, 2005, 8:19:28 PM, you wrote:
> On Tue, 15 Nov 2005, Dmitry Stogov wrote:
>> On Tue, 15 Nov 2005, Derick Rethans wrote:
>>
>> > On Tue, 15 Nov 2005, Dmitry Stogov wrote:
>> >
>> > > dmitry Tue Nov 15 11:49:44 2005 EDT
>> > >
>> > > Modified files
Dmitry Stogov schrieb:
> This should solve the problem.
Okay, I reverted the patch for now and will {think about|work on} this.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Interna
Hmm, this is an idea. (I don't know yet if it good or bad)
Current problem occurs because the same debug_backtrace is called during
exception creation.
Probably we can disable storing of "object" in case of backtrace for
exception.
This should solve the problem.
Thanks. Dmitry.
> -Original Me
Marcus Boerger schrieb:
> what do you think comes out first, 5.1.1 or 6.0 ?
PHP 5.1.1, of course. But as I cannot yet commit to PHP_5_1 I did not
want to have the patch in HEAD without a NEWS entry.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5
Hello Sebastian,
what do you think comes out first, 5.1.1 or 6.0 ?
marcus
Saturday, October 29, 2005, 12:36:04 PM, you wrote:
> Jani Taskinen schrieb:
>> If you're going to add it in PHP_5_1 branch,
>> why are you adding the thing in HEAD NEWS file?
> Because for now it is in HEAD only. Once
Derick Rethans schrieb:
> That seems to work fine already
Even better :-)
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscri
On Sun, 16 Oct 2005, Derick Rethans wrote:
> > In any case, as I could never think of a better syntax to deal with the
> > somewhat harmless ambiguity of default value and "allowing" null, I don't
> > mind
> > having this patch. It should be documented though that this syntax comes to
> > serve b
On Sun, 16 Oct 2005, Sebastian Bergmann wrote:
> Andi Gutmans schrieb:
> > I'm talking about the following function decleration:
> >
> > function testNull(MyClass $obj = 1) {
> > }
>
> The following should work, too, to allow optional, type-hinted Array
> parameters:
>
>function someMetho
Andi Gutmans schrieb:
> I'm talking about the following function decleration:
>
> function testNull(MyClass $obj = 1) {
> }
The following should work, too, to allow optional, type-hinted Array
parameters:
function someMethod(Array $array = array()) {
}
--
Sebastian Bergmann
The bug was introduced with Antony's patch - fix #33771 (error_reporting
falls to 0 when @ was used inside try/catch block).
"make install" was crached during PEAR installation.
Thanks. Dmitry.
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Friday, Septemb
1 - 100 of 300 matches
Mail list logo
