> I'd like to know, if it's possible to create a php function
> in C which modify the line number and the php interpreter.
> It will be very useful for tools generating php code (lex,
> yacc, smarty etc).
> For exemple:
> echo __FILE__//show parser.php
> __setLine(8);__setFile('parser.y');
> toto()
Hello internals,
i am now done with most bigger parts of 5.2 Todo and the remainder
is a bunch of fixes engine wise some folks already found during the
MFH phase. Right now my test results look like (see below). Whilethis
looks quite good on the first glance it is actually a big problem that
onl
Marcus Boerger wrote:
no, the compiler generates code that makes the executor generate the
variable and complain prior to performing the call.
The executor doesn't complain about unset variables prior to calling
functions by reference, so I was thinking it could be modified to also
not com
Hello internals,
__get() and __set() are great, but 90% of the time, I find myself
using them to create public readonly properties.
The only problem with this is it is horridly inefficient, consuming
at least 1 function call and one switch statement (or equiv) per
property read.
Woul
On 12.05.2006 03:05, D. Dante Lorenso wrote:
Antony Dovgal wrote:
On 12.05.2006 02:49, D. Dante Lorenso wrote:
* #define ZEND_SEND_BY_REF 1
This one is what you need.
I don't think it is. The variable did not exist before the function was
called and should STILL not exist afterwards.
Hello D.,
Friday, May 12, 2006, 1:10:41 AM, you wrote:
> Marcus Boerger wrote:
>> no, the compiler generates code that makes the executor generate the
>> variable and complain prior to performing the call.
>>
> The executor doesn't complain about unset variables prior to calling
> functions
Antony Dovgal wrote:
On 12.05.2006 02:49, D. Dante Lorenso wrote:
* #define ZEND_SEND_BY_REF 1
This one is what you need.
I don't think it is. The variable did not exist before the function was
called and should STILL not exist afterwards. I believe when you pass
by reference, the v
Hello D.,
no, the compiler generates code that makes the executor generate the
variable and complain prior to performing the call. In a zend extension
you could try to hook into that process.
marcus
Friday, May 12, 2006, 12:49:45 AM, you wrote:
> All,
> Is there a way to define a function in
On 12.05.2006 02:49, D. Dante Lorenso wrote:
All,
Is there a way to define a function in an extension which would not
require a passed in variable to exist? In other words, can ZE be
modified to allow extensions to not trigger E_NOTICE warnings if an
unset variable is passed to a function wh
All,
Is there a way to define a function in an extension which would not
require a passed in variable to exist? In other words, can ZE be
modified to allow extensions to not trigger E_NOTICE warnings if an
unset variable is passed to a function which does not care if the var is
set?
I can
Hello bertrand,
one of the thinks i work on is this: http://gcov.php.net
Thursday, May 11, 2006, 11:57:09 PM, you wrote:
> Marcus Boerger wrote:
>> Hello bertrand,
>>
>> we already have an infrastructure that allows you to run tests.
>> Just do: make test
> I forgot the point:
> I said in
Marcus Boerger wrote:
Hello bertrand,
we already have an infrastructure that allows you to run tests.
Just do: make test
I forgot the point:
I said infrastucture as what would need php to be complete ,
with a minimal build (with nothing) 45% of the tests are skipped.
Anyway, unit tests are
Bonsoir
Marcus Boerger wrote:
Hello bertrand,
we already have an infrastructure that allows you to run tests.
Just do: make test
I guess I was aware of that,
even if I'm more used to the pear format of .phpt
make test is easy
reporting failing ones is not
I just told I would try
Regards
--
On Thu, May 11, 2006 3:58 pm, Rasmus Lerdorf wrote:
> Marcus has a point here. People are complaining loudly about bugs
> being
> introduced. These bugs would have been found quicker if we had better
> tests. If every complaint included a nice clean .phpt test file that
> can be dropped right in
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Richard Lynch wrote:
> On Thu, May 11, 2006 2:30 pm, Jasper Bryant-Greene wrote:
>> From a pure computer science point of view, the above makes complete
>> sense. Null means unknown value, so nothing is equal to it, not even
>> another null (becau
On Thu, May 11, 2006 2:30 pm, Jasper Bryant-Greene wrote:
> Jared Williams wrote:
>>
>> Interesting logic break too...
>>
>> $foo = new stdClass();
>> if ($foo == null || $foo != null) { echo 'Never gets echoed'; }
>
> From a pure computer science point of view, the above makes complete
> sense. Nu
Brian Moon wrote:
Marcus Boerger wrote:
<[EMAIL PROTECTED]>
However i said that already on IRC nobody is taking care on tests but
complain is what you guys are all goo at! Instead of screaming and
whining after a release you should write tests. When looking at <50%
coverage from a test run and @
Hello Brian,
sure i wanted to express to things. First 5.2 is work in (heavy) progress
and second that the lack of tests causes a bunch of unnecessary problems.
That said i ask everybody again to write tests for stuff he/she doesn't like
to change in case it hasn't been decided to change.
best
Marcus Boerger wrote:
<[EMAIL PROTECTED]>
However i said that already on IRC nobody is taking care on tests but
complain is what you guys are all goo at! Instead of screaming and
whining after a release you should write tests. When looking at <50%
coverage from a test run and @ <5K tests for a be
On 5/11/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Hello Pierre,
only problem is, all that stuff is somehow dependend on one another. I started
with
smaler chunks but it simply was not doable.
Well, I see many parts that should have been commited separatelly.
Also we discussed the chang
>
> Jared Williams wrote:
> >
> > Interesting logic break too...
> >
> > $foo = new stdClass();
> > if ($foo == null || $foo != null) { echo 'Never gets echoed'; }
>
> From a pure computer science point of view, the above makes
> complete sense. Null means unknown value, so nothing is equal
>
> In case you miss it, this discussion is about breakages within the
> same major version.
I am talking strictly from a Major Release standpoint, which is why I
titled it PHP6 compiler features...
...
My understanding is that this type of change would be slightly massive
undertaking to the
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Sean Coates wrote:
>> In any event, I'm just trying to indicate that others may also face
>> issues if they have PHP4 apps with these sorts of keywords in them.
>
> "try" has been a reserved word (documented) since Fri Oct 1 08:07:16
> 2004 UTC:
> In any event, I'm just trying to indicate that others may also face
> issues if they have PHP4 apps with these sorts of keywords in them.
"try" has been a reserved word (documented) since Fri Oct 1 08:07:16
2004 UTC:
http://cvs.php.net/viewcvs.cgi/phpdoc/en/appendices/reserved.xml?view=diff&r1=1
Hello Pierre,
only problem is, all that stuff is somehow dependend on one another.
I started with smaler chunks but it simply was not doable. Also we discussed
the changes for weeks if not to say for months. That a few things fail to
work is the lack of tests i already mentioned and also of caus
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Pierre wrote:
> On 5/11/06, Jasper Bryant-Greene <[EMAIL PROTECTED]> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: RIPEMD160
>>
>> Just to add my 2c, I am currently trying to migrate a legacy PHP4
>> application to PHP5
>
> In case you mi
On 5/11/06, Jasper Bryant-Greene <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Just to add my 2c, I am currently trying to migrate a legacy PHP4
application to PHP5
In case you miss it, this discussion is about breakages within the
same major version.
--Pierre
nothing
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello bertrand,
we already have an infrastructure that allows you to run tests.
Just do: make test
Thursday, May 11, 2006, 9:39:30 PM, you wrote:
> Bonsoir,
> Marcus Boerger wrote:
>> Hello Jared,
>>
>> this is the first prodictive mail in this thread, we can easily
>> extend the .phpt sys
Bonsoir,
Marcus Boerger wrote:
Hello Jared,
this is the first prodictive mail in this thread, we can easily
extend the .phpt system to have different expectations for different
versions of php. That was we can handle stuff that slightly changes
like spell correction in error messages and such.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Just to add my 2c, I am currently trying to migrate a legacy PHP4
application to PHP5, and one of the huge hurdles is a set of classes
representing a group of tasks, each class having a method called try().
These classes are used in over 100,000 l
Jared Williams wrote:
>
> Interesting logic break too...
>
> $foo = new stdClass();
> if ($foo == null || $foo != null) { echo 'Never gets echoed'; }
From a pure computer science point of view, the above makes complete
sense. Null means unknown value, so nothing is equal to it, not even
another
On 5/11/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Hello Derick,
Thursday, May 11, 2006, 2:15:53 PM, you wrote:
> Hello!
> While I welcome new developments in either procedural or OO interfaces
> in PHP I do not agree with breaking BC (between 5.1 and 5.2 in this
> case) just for the sake o
Hello guys,
sorry but i worked >12 hours on patch that brought half of the todo list
for 5.2 because all that stuff is unluckily interlinked.and guess i can
make changes in a dev tree as well as there might be errors in head and i
even more might copy errors from head to the dev treetoo
Hello Derick,
Thursday, May 11, 2006, 2:15:53 PM, you wrote:
> Hello!
> While I welcome new developments in either procedural or OO interfaces
> in PHP I do not agree with breaking BC (between 5.1 and 5.2 in this
> case) just for the sake of OO purity. In this example there is the
> following
Marian Kostadinov wrote:
There is an issue about error_reporting setting in php.ini. I took my php
5.1 php.ini file and used it for 5.2. Strangely it seemed that E_STRICT
suddenly turned on.
Is this an intended change or a bug?
AFAIK it was intended to change E_ALL to include E_STRICT in 5.2+
> Hello William,
>
> as long as php has no goto no such generator is capable of
> generating php code.
> When that changes we want to have
> something alike of course. But actuall it is already in HEAD
> ... So thenWhy not cimply go with this:
> #line
> to simple becuase the tools in
Hello Jared,
this is the first prodictive mail in this thread, we can easily
extend the .phpt system to have different expectations for different
versions of php. That was we can handle stuff that slightly changes
like spell correction in error messages and such.
Now not to you Jared but to all:
Hello William,
as long as php has no goto no such generator is capable of generating php
code. When that changes we want to have something alike of course. But
actuall it is already in HEAD ... So thenWhy not cimply go with this:
#line
to simple becuase the tools in question would already
On Thu, May 11, 2006 7:47 am, Sebastian Bergmann wrote:
> Maybe we could set up a testing system that runs the tests from
> PHP_4_4,
> PHP_5_0, PHP_5_1, and HEAD and shows the differences? That way we
> would
> notice that a test that passed with a previous version fails with a
> newer one.
+1
Precisely. The point I was trying to make is that there should be fewer
restrictions on method names of classes so that developers that are
maintaining some distributable classes can keep the API clean. I've
found myself in a situation where instead of using a method call
isset(), I must use
Pierre wrote:
I forgot to mention how vicious such changes can be. Most of times the
related tests are "updated" in the same commit (or right after) to
follow the new behavior. Making nearly impossible to know about the
breakages without duplicating core tests in our apps. Also commit
messages or
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: 11 May 2006 15:07
> To: PHP Developers Mailing List
> Subject: Re: [PHP-DEV] Stop Breaking Our Apps For the Sake of OO
>
> On Thu, 11 May 2006, Derick Rethans wrote:
>
> > While I welcome new developments in
On Thu, 11 May 2006, Andi Gutmans wrote:
> Yep I agree but unfortunately it seems that most people on the dev team either
> don't care or don't speak up.
> Also, I asked time and again to add BC breaking changes to an UPGRADING file.
> Had that been done we would have noticed and could have reacte
Yep I agree but unfortunately it seems that most people on the dev
team either don't care or don't speak up.
Also, I asked time and again to add BC breaking changes to an
UPGRADING file. Had that been done we would have noticed and could
have reacted.
At 05:17 AM 5/11/2006, Derick Rethans wro
Pierre wrote:
On Thu, 11 May 2006 14:15:53 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
Hello!
While I welcome new developments in either procedural or OO
interfaces in PHP I do not agree with breaking BC (between 5.1 and
5.2 in this case) just for the sake of OO purity. In this exam
On Thu, 11 May 2006, Derick Rethans wrote:
> While I welcome new developments in either procedural or OO interfaces
> in PHP I do not agree with breaking BC (between 5.1 and 5.2 in this
> case) just for the sake of OO purity. In this example there is the
> following class:
I've one more of t
> Pierre wrote:
> > I forgot to mention how vicious such changes can be. Most
> of times the
> > related tests are "updated" in the same commit (or right after) to
> > follow the new behavior. Making nearly impossible to know about the
> > breakages without duplicating core tests in our apps.
Pierre wrote:
> I forgot to mention how vicious such changes can be. Most of times the
> related tests are "updated" in the same commit (or right after) to
> follow the new behavior. Making nearly impossible to know about the
> breakages without duplicating core tests in our apps. Also commit
> mes
On Thu, 11 May 2006 14:15:53 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> Hello!
>
> While I welcome new developments in either procedural or OO
> interfaces in PHP I do not agree with breaking BC (between 5.1 and
> 5.2 in this case) just for the sake of OO purity. In this example
> t
On Thu, 11 May 2006 14:15:53 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> Hello!
>
> While I welcome new developments in either procedural or OO
> interfaces in PHP I do not agree with breaking BC (between 5.1 and
> 5.2 in this case) just for the sake of OO purity.
... or any other r
On Wed, 26 Apr 2006, Edin Kadribasic wrote:
> Marcus Boerger wrote:
> > It is just some decision that was taken that the newer OO stuff should be a
> > bit more strict.
>
> I don't remember any such decision. I don't even remember a discussion about
> it. I'm aware of the efforts of some people t
Hello!
While I welcome new developments in either procedural or OO interfaces
in PHP I do not agree with breaking BC (between 5.1 and 5.2 in this
case) just for the sake of OO purity. In this example there is the
following class:
which now with PHP 5.2 throws:
[EMAIL PROTECTED]:/hom
There is an issue about error_reporting setting in php.ini. I took my php
5.1 php.ini file and used it for 5.2. Strangely it seemed that E_STRICT
suddenly turned on.
Is this an intended change or a bug?
E_STRICT and E_RECOVERABLE_ERROR are now part of E_ALL
-Hannes
--
PHP Internals - PHP Runti
i'll second that idea, but not the syntax.
template engine such smarty, and compiler compiler, need it really.
Hello,
I'd like to know, if it's possible to create a php function in C which
modify the line number and the php interpreter. It will be very useful
for tools generating php code (lex, yacc, smarty etc).
For exemple:
echo __FILE__//show parser.php
__setLine(8);__setFile('parser.y');
toto();
Will
56 matches
Mail list logo
