Okay Andi, the script in this message is as simple as it gets. I used a
syslog file to create a load of data in this case, but of course you can use
any (text) file for this.
#!/usr/bin/php5
This is the output it gives me (PHP 5.0.4 btw):
40232
309528
578880
846720
1114560
1382400
1650240
19180
Yep and it works great.
At 07:34 AM 8/10/2005 +0200, Sebastian Bergmann wrote:
steve roussey schrieb:
> I'm assuming that the 4.3.0 Release Announcement that FastCGI
> was removed is bogus or reversed.
It was merged into the CGI SAPI module.
--
Sebastian Bergmann http://w
steve roussey schrieb:
> I'm assuming that the 4.3.0 Release Announcement that FastCGI
> was removed is bogus or reversed.
It was merged into the CGI SAPI module.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6
OK thanks.
At 08:05 PM 8/9/2005 -0700, Frank M. Kromann wrote:
Hi Andi,
I'll make it work with both versions tonight. If I can't get that to work
I'll revert the latest fix so we can release.
- Frank
> Guys,
>
> Any idea when you'll resolve this issue? I'd like to roll tomorrow or
the
> day a
I finally got a chance to test under Windows today, and there was a
variable that was not being initialized under ZTS mode that was causing
problems in Windows. The attached patch is correctly initializing it. Also,
the namespace_anonymous.php file was missing from the patch, which the
attached no
Hi Andi,
I'll make it work with both versions tonight. If I can't get that to work
I'll revert the latest fix so we can release.
- Frank
> Guys,
>
> Any idea when you'll resolve this issue? I'd like to roll tomorrow or
the
> day after.
> Thanks,
> Andi
>
> At 09:12 PM 8/9/2005 +0200, Marcus B
steve roussey wrote:
> On 8/9/05, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
>
>>PHP by default compiles as a non-pic shared library now which is just as
>>fast as a static build inside Apache since it is the pic stuff that
>>slows down a DSO. So there is really no need for static builds anymore,
Guys,
Any idea when you'll resolve this issue? I'd like to roll tomorrow or the
day after.
Thanks,
Andi
At 09:12 PM 8/9/2005 +0200, Marcus Boerger wrote:
Hello Frank,
this broke my build again. Before i was able to support 02a, 0.3beta1 (the
latest according to the web) and with/without th
steve roussey wrote:
Someone else emailed me about using FastCGI with Apache 2.1/event but
I just figured that there would be a significant slowdown using
FastCGI rather than a module/handler. (Currently I compile PHP into
Apache statically and turn off Apache's dynamic module loading ability
--
On 8/9/05, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> PHP by default compiles as a non-pic shared library now which is just as
> fast as a static build inside Apache since it is the pic stuff that
> slows down a DSO. So there is really no need for static builds anymore,
> unless you happen to be
On Wed, Aug 10, 2005 at 01:03:06AM +0200, Marcus Boerger wrote:
> Wednesday, August 10, 2005, 12:38:49 AM, you wrote:
> > On Tue, Aug 09, 2005 at 02:07:27PM -0400, George Schlossnagle wrote:
> >>
> >> if(class_exists('MyFoo') && $obj instanceof MyFoo) { }
> >
> > Unfortunately, class_exists() stil
Hello Daniel,
RTFM: try class_exists(..., false)
marcus
Wednesday, August 10, 2005, 12:38:49 AM, you wrote:
> On Tue, Aug 09, 2005 at 02:07:27PM -0400, George Schlossnagle wrote:
>>
>> if(class_exists('MyFoo') && $obj instanceof MyFoo) { }
> Unfortunately, class_exists() still calls __autol
On Tue, Aug 09, 2005 at 02:07:27PM -0400, George Schlossnagle wrote:
>
> if(class_exists('MyFoo') && $obj instanceof MyFoo) { }
Unfortunately, class_exists() still calls __autoload(). Un-deprecating
is_a() seems to be an easy way to resolve this situation.
--Dan
--
T H E A N A L Y S I S
Marcus Boerger schrieb:
regarding static props the solution is to define another hash table
in the class_entry that holdes the initial values for the static
variables. During minit these would be copied to the used hash table,
done. But even though the solution is pretty easy i do not know if we
That is great to know. In that case, I won't worry about threading
again. I'm assuming that the 4.3.0 Release Announcement that FastCGI
was removed is bogus or reversed.
Unfortunately my source for mysql connection pooling was never
upgraded to support 4.1's APIs. If anyone knows one, pass it by m
Hi Steve,
From my experiences, FastCGI performance is comparable to mod_php.
Andi
At 02:24 PM 8/9/2005 -0700, steve roussey wrote:
On 8/9/05, Andreas Korthaus <[EMAIL PROTECTED]> wrote:
> By using lighttpd with fastcgi we seperate the webserver process from
> php processes (which could even wo
steve roussey wrote:
> On 8/9/05, Andreas Korthaus <[EMAIL PROTECTED]> wrote:
>
>>By using lighttpd with fastcgi we seperate the webserver process from
>>php processes (which could even work on other machines)...
>
>
> Someone else emailed me about using FastCGI with Apache 2.1/event but
> I jus
On Tue, 2005-08-09 at 21:49 +0100, Nuno Lopes wrote:
> BTW, there was an error in your patch: it cleans the *.gcno files (which are
> generated at compile time) in cov_gen_clean() before running lcov, thus
> breaking the proccess.
Opps. I'll fix that when I commit. As soon as we get the parsers
On 8/9/05, Andreas Korthaus <[EMAIL PROTECTED]> wrote:
> By using lighttpd with fastcgi we seperate the webserver process from
> php processes (which could even work on other machines)...
Someone else emailed me about using FastCGI with Apache 2.1/event but
I just figured that there would be a sig
Weiredly had the wrong adress in my contacts. So, here's what was
intended to get here...
Original Message
Hi all!
Sebastian has blogged [1] about FrOSCon, a pondon to FOSDEM in Germany,
St. Augustin. If there is interesst, I'd love to see a PHP/PECL/PEAR
room there. Sebastian
Hello Wez,
i fixed some bugs in re2c since -o was added. Some of those were serious
ones. Whether they affect pdo i cannot tell but for one issue i know that it
may affect ext/standard usage (depending on the compiler iirc). Maybe jani
can recall the reasons why and when we increased the re2c ver
No, I'm not (both not the only one using an older version, nor am I
necessarily using an older version).
Until someone points out a re2c bug that actually impacts PHP, I'm in
no rush to run around upgrading more than 20 machines.
--Wez.
On 8/9/05, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> Hell
On Aug 9, 2005, at 4:55 PM, Wez Furlong wrote:
JFYI: -o doesn't work on all versions of re2c
Since when has PHP been concerned about not requiring the most-most
recent version of a library, let alone a development tool?
George
--Wez.
On 8/9/05, Nuno Lopes <[EMAIL PROTECTED]> wrote:
Hello Wez,
just to remind you: you are the only one using an old unsupport version
that doesn't come with -o.
marcus
Tuesday, August 9, 2005, 10:55:43 PM, you wrote:
> JFYI: -o doesn't work on all versions of re2c
> --Wez.
> On 8/9/05, Nuno Lopes <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I'v
JFYI: -o doesn't work on all versions of re2c
--Wez.
On 8/9/05, Nuno Lopes <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've already had a change to test your patch (I've even have asked my
> university for a server to put ithe reports on-line).
> I've also came into this issue, which happens because re
Hello Nuno,
that's also absolutley correct for most .re'S.
Tuesday, August 9, 2005, 10:49:02 PM, you wrote:
> Hi,
> I've already had a change to test your patch (I've even have asked my
> university for a server to put ithe reports on-line).
> I've also came into this issue, which happens be
Andi Gutmans wrote:
My the way, the performance argument wouldn't work because even if this
would be supported, we'd have to first "try" and load the class to make
sure we can actually check the instanceof, and only if the class doesn't
load then we would return false. So you won't save that st
Hello John,
for the .re ones i could simply release re2c 0.9.10 and you use the new
switch we especially made for that. If i knew we were going for 5.1 i had
probably done that at OSCON but i didn't see any action required until just
now.
best regards
marcus
Tuesday, August 9, 2005, 10:44:01 P
Hi,
I've already had a change to test your patch (I've even have asked my
university for a server to put ithe reports on-line).
I've also came into this issue, which happens because re2c is called in the
wrong way (the output is printed to stdout, rather than directly to the
file). Those files
I also wrote one, i don't care which we use... it's a 5 line shell
script :)
On Tue, 2005-08-09 at 16:40 -0400, Wez Furlong wrote:
> IIRC, we have a script that does this already for our release
> tarballs; should save some effort.
>
> --Wez.
>
> On 8/9/05, John Coggeshall <[EMAIL PROTECTED]> wr
IIRC, we have a script that does this already for our release
tarballs; should save some effort.
--Wez.
On 8/9/05, John Coggeshall <[EMAIL PROTECTED]> wrote:
> Before we deep-freeze the CVS, I'd like to get my GCOV stuff committed.
> The changes are relatively minor and I've already run it past A
Before we deep-freeze the CVS, I'd like to get my GCOV stuff committed.
The changes are relatively minor and I've already run it past Andi. I'm
trying to get around one last problem that maybe someone else can take
care of:
The basic issue is that our parsers have broken file/line preprocessor
dir
At 09:55 PM 8/9/2005 +0200, Pierre-Alain Joye wrote:
On Tue, 09 Aug 2005 12:44:59 -0700
Andi Gutmans <[EMAIL PROTECTED]> wrote:
> But that's a good point. For the few frameworks that might
> require such functionality they can use class_exists() or other
> methods. That doesn't mean we should ch
Hello George,
Tuesday, August 9, 2005, 9:48:22 PM, you wrote:
> On Aug 9, 2005, at 3:25 PM, Andi Gutmans wrote:
>> I think Unicode warrants a major version. I'd go with PHP 6 and aim
>> to release it before Perl 6 :)
>> From judging by a Perl 6 talk we attended at OSCON, that might
>> actua
On Tue, 09 Aug 2005 12:44:59 -0700
Andi Gutmans <[EMAIL PROTECTED]> wrote:
> But that's a good point. For the few frameworks that might
> require such functionality they can use class_exists() or other
> methods. That doesn't mean we should change instanceof for
> mainstream usage which is 99.99%.
At 09:41 PM 8/9/2005 +0200, Pierre-Alain Joye wrote:
On Tue, 09 Aug 2005 12:25:27 -0700
[EMAIL PROTECTED] (Andi Gutmans) wrote:
> I think Unicode warrants a major version. I'd go with PHP 6 and
> aim to release it before Perl 6 :)
> From judging by a Perl 6 talk we attended at OSCON, that might
Per my online conversation with Andi, I will be committing the gcov
stuff prior to the deep-freeze tomorrow morning -- expect a cvs commit
and a follow-up e-mail on usage early tomorrow morning.
John
On Mon, 2005-08-08 at 23:11 -0700, Andi Gutmans wrote:
> At 07:57 AM 8/9/2005 +0200, Sebastian Be
On Aug 9, 2005, at 3:25 PM, Andi Gutmans wrote:
I think Unicode warrants a major version. I'd go with PHP 6 and aim
to release it before Perl 6 :)
From judging by a Perl 6 talk we attended at OSCON, that might
actually be a realistic goal.
I think that's more than a 'might'.
George
--
P
At 02:07 PM 8/9/2005 -0400, George Schlossnagle wrote:
To duplicate the old semantic now you need to do:
if(class_exists('MyFoo') && $obj instanceof MyFoo) { }
which is definitely uglier than
if(is_a($obj, 'MyFoo')) {}
George
But that's a good point. For the few frameworks that might requir
steve roussey wrote:
> The setup we are striving for is to keep connections open all the way
down the chain to the database. Ideally this would mean that we would
use Apache 2.2 with the event MPM to hold user connections. Then the
PHP threads would ideally hold persistent connections to the da
steve roussey wrote:
> I know my name can be easily traced to a website I own that only gets
> about 10M pv/day but I also work as a consultant for another that gets
> an order of magnitude more. So perhaps you do get more then them and
> get 1B pv/day and your dad can beat up my dad. Ug. Strike th
We've made a start a long time ago, and we do our best to keep all of PHP
thread-safe. On paper it is. When a bug appears we fix it. Is it a risk to
run it... I think it is but I have seen people running it successfully on
IIS for a long time. (I still think that's a bad idea though).
Andi
At
On Tue, 09 Aug 2005 12:25:27 -0700
[EMAIL PROTECTED] (Andi Gutmans) wrote:
> I think Unicode warrants a major version. I'd go with PHP 6 and
> aim to release it before Perl 6 :)
> From judging by a Perl 6 talk we attended at OSCON, that might
> actually be a realistic goal.
No rush please... Bet
Can you send a complete script which also passes $data that reproduces the
problem? Thanks.
At 05:27 PM 8/9/2005 +0200, Ron Korving wrote:
The problem occurs in this particular situation:
public function process($data)
{
$largeResultSet = $this->xmlParser->parseString($data);
foreach ($la
Hi Ilia,
I think it's hard to define ahead of time, but usually I prefer allowing
non-BC breaking and non-infrastructure changes, for example, a new
function, a new optional parameter to a function, some minor functionality...
If it's a change in the infrastructure of PHP, then chances are that
On Tue, 09 Aug 2005 12:29:45 -0700
Andi Gutmans <[EMAIL PROTECTED]> wrote:
> we'd have to first "try" and load the class to make
> sure we can actually check the instanceof
Pardon me? :)
As I said in my 2nd post about this topic, the problem (and only
problem here) is that in the lexer, the rig
Hi Michael,
I agree that this might be the right way to resolve the current issues. I
mentioned it to Marcus at OSCON.
Andi
At 02:19 PM 8/9/2005 +0200, Michael Wallner wrote:
I wrote:
> Therefore I'd suggest changing that so that they'll be
> initialized and destructed for each request, whi
My the way, the performance argument wouldn't work because even if this
would be supported, we'd have to first "try" and load the class to make
sure we can actually check the instanceof, and only if the class doesn't
load then we would return false. So you won't save that step of trying to
load
Andi Gutmans wrote:
I am not stubborn. I just think this has close to 0 use in real-life (or
you're doing some weird coding). In any case, for the one in a million
case, I think Reflection is good enough.
I worded my example a bit wrong. I dont like people loading PEAR.php on
demand. However
On 8/9/05, steve roussey <[EMAIL PROTECTED]> wrote:
> > My stuff is far bigger and busier than yours
>
> My spewing of stuff...
I often write things to make me feel better and delete them before
hitting send. Sort of stream of consciousness that I edit before
sending. IRasmus, apologize for being
I think Unicode warrants a major version. I'd go with PHP 6 and aim to
release it before Perl 6 :)
From judging by a Perl 6 talk we attended at OSCON, that might actually be
a realistic goal.
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
I am not stubborn. I just think this has close to 0 use in real-life (or
you're doing some weird coding). In any case, for the one in a million
case, I think Reflection is good enough.
Andi
At 08:40 AM 8/9/2005 +0200, Michael Wallner wrote:
Hi Andi Gutmans, you wrote:
> You are wrong because
Wez Furlong wrote:
On 8/9/05, Pierre-Alain Joye <[EMAIL PROTECTED]> wrote:
5.x - small additions (in my case, gd updates and merge,
xmlwriter)
This is what PECL is for. We're trying to move stuff out of the core
so that these kinds of updates are easier for everyone to work on and
On Aug 9, 2005, at 3:12 PM, steve roussey wrote:
On 8/8/05, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
3. Problems with thread-safety of modules
You missed the most serious one. Thread safety problems in random
libraries you link in and we have absolutely no control over those.
OK, I am
On 8/8/05, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> > 3. Problems with thread-safety of modules
>
> You missed the most serious one. Thread safety problems in random
> libraries you link in and we have absolutely no control over those.
OK, I am confused. I always thought (an assumption with n
Hello Michael,
Tuesday, August 9, 2005, 2:19:25 PM, you wrote:
> I wrote:
>> Therefore I'd suggest changing that so that they'll be
>> initialized and destructed for each request, which means
>> that there will need to be some form of hooks, which
> Let me change that part... :)
> There's no n
Bitch, where are my page views?
-Andrei
On Aug 9, 2005, at 10:26 AM, Darrell Brogdon wrote:
I think by "client(s)" you mean JOHNS (Justified Output with Heuristic
Notifications Server).
On Aug 9, 2005, at 11:14 AM, Jessie Hernandez wrote:
I am not familiar with PIMP, but I would not get it
> Now that we branched it's time to rename HEAD to something else than 5.1
> in order to have different version numbers. Although the name PHP 5.5
> was mentioned before, I do think we should call it PHP 6.0. As the
> Unicode support is quite a drastic change. Going with PHP 6.0 also
> allows u
On 8/9/05, Pierre-Alain Joye <[EMAIL PROTECTED]> wrote:
> 5.x - small additions (in my case, gd updates and merge,
> xmlwriter)
This is what PECL is for. We're trying to move stuff out of the core
so that these kinds of updates are easier for everyone to work on and
use.
--Wez.
--
PHP
On Aug 9, 2005, at 5:56 AM, Pierre-Alain Joye wrote:
On Tue, 9 Aug 2005 10:15:15 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
This technique is already frequently used to cope with lazy
loaded code, which even with cached code compile
Maybe a little late throwing my 2 cents in, but here they are anyway.
If you're writing an app that can optionally use a component that is
not present, there is nothing conceptually wrong with calling
instanceof to determine if that support is present; PHP should not
blow up. If the class is not l
I think by "client(s)" you mean JOHNS (Justified Output with
Heuristic Notifications Server).
On Aug 9, 2005, at 11:14 AM, Jessie Hernandez wrote:
I am not familiar with PIMP, but I would not get it in 6.0 until we
have
HOES (HTML Output Extension Server) complete. Then we can start on the
Hi Ron,
On Tuesday 09 August 2005 19:09, Ron Korving wrote:
> Nonetheless, Rasmus, isn't it something to work on? Like Steve said, #1 and
> #2 can be accomplished, and that would at least be a good start. You are
> right about the libraries, but in time, even these may become thread safe
> (of cou
If we find thread safety problems in PHP we will fix them, of course.
It's not like we ignore them. Same goes for extensions, except for
those which are specifically designed to access libraries that show no
signs of ever becoming thread safe.
At the same time, you need to recognize that develope
I am not familiar with PIMP, but I would not get it in 6.0 until we have
HOES (HTML Output Extension Server) complete. Then we can start on the
client(s) for 6.1 :-).
--
Jessie
"David Zülke" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> > 6.0 - to define, for now we have two c
Nonetheless, Rasmus, isn't it something to work on? Like Steve said, #1 and
#2 can be accomplished, and that would at least be a good start. You are
right about the libraries, but in time, even these may become thread safe
(of course, likely not by anyone from the PHP-community). Why is this
thread
Andi et al,
I am hoping to finish rough draft of HTTP input decoding today. I'd
rather not merge in half-finished stuff. Besides that, do you think we
need a write up on what has been changed in the core, new APIs,
function upgrade guidelines, etc?
Ping me on IM if you can.
-Andrei
On Aug
On Aug 9, 2005, at 12:18 AM, Derick Rethans wrote:
Ah,you meant that __have_prop() should always return the full array of
things that are supported. That is fine, as long as we can have this
generated from the "abstract" properties that people declared (so that
they can be documented properly to
On Tue, Aug 09, 2005 at 02:31:08PM +0800, Alan Knowles wrote:
>
> It is not about the fact we 'can' load the class, but that we dont
> 'want' to load the class.. - it's a waste of resources, memory, cpu etc.
> just for the sake of CS perfection..
Hear, hear!
--Dan
--
T H E A N A L Y S I S
The problem occurs in this particular situation:
public function process($data)
{
$largeResultSet = $this->xmlParser->parseString($data);
foreach ($largeResultSet as &$item)
{
throw new Exception("error");
}
}
It only happens if the exception is thrown from within the foreach(). It
s
It is very likely that this has something to do with DOM. It's a huge piece
of code though, making it hard to test where the problem really lies.
""Ron Korving"" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> I've noticed that in a script of mine, memory consumption can explode
qu
I've noticed that in a script of mine, memory consumption can explode quite
drastically when Exceptions are thrown, opposed to very normal memory
consumption when exceptions are not thrown.
This is the idea:
process();
}
catch (Exception $e)
{
$errors[] = $e->getMessage();
}
}
?>
Whe
Derick Rethans wrote:
> I see it as:
> 4.4 - no new features, no new additions. Just bugfixes.
> 5.1 - no new major features, just smaller additions.
> 6.0 - brand new experimental stuff.
This breakdown looks good, although it'd be nice to quantify just what
kind of "smaller additions" are accept
I wrote:
> Therefore I'd suggest changing that so that they'll be
> initialized and destructed for each request, which means
> that there will need to be some form of hooks, which
Let me change that part... :)
There's no need for any "hooks" as there's already
RINIT() and RSHUTDOWN(), so I guess
Quoting Weyert de Boer <[EMAIL PROTECTED]>:
Hi
I'm not sure what you guys are discussing here, but it's definitely
not up to any non-contributor to decide which version number we
pick. And making it dependable on whether some patch goes in or not
doesn't make sense at all.
Such a kind way
As already mentioned earlier, there does not seem to be
any extension or core code using static properties for
internal classes.
I'd like to request a change in their behaviour/implementation.
Currently static properties of internal classes are allocated
persitently which limits their usage and h
thank you for the response.
I will incorporate the feedback and send the updated ones.
Regards,
Rathna.
On Tue, 9 Aug 2005 13:45:06 +0200 (CEST), "Derick Rethans"
<[EMAIL PROTECTED]> said:
> On Tue, 9 Aug 2005, Rathna N wrote:
>
> > Sorry, I forgot to add subject line to the old mail.
>
> the [
On Tue, 9 Aug 2005, Rathna N wrote:
> Sorry, I forgot to add subject line to the old mail.
the [EMAIL PROTECTED] list would be the best list for this subject.
As for the tests, it would be nice if you could provide a unified diff
against CVS's HEAD. That's much easier than have to download a .zi
Sorry, I forgot to add subject line to the old mail.
On Mon, 08 Aug 2005 23:56:24 -0700, "Rathna N" <[EMAIL PROTECTED]>
said:
> Hi All,
> this is first my post to this list.
> I'm interested to do QA related contributions to PHP.
>
> Pls do find the test scripts for Calendar extension at below l
On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
> > If we want to include xmlwriter at all in the
> > default distribution is another discussion. (So that should go to
> > another thread IMO).
>
> The discussion is already done and we agreed. It did not make it in
> 5.1 for various reasons. I only s
On Tue, 9 Aug 2005 13:02:47 +0200 (CEST)
Derick Rethans <[EMAIL PROTECTED]> wrote:
> On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
>
> > On Tue, 9 Aug 2005 12:47:50 +0200 (CEST)
> > [EMAIL PROTECTED] (Derick Rethans) wrote:
> >
> > > On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
> > >
> > > > But
On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
> On Tue, 9 Aug 2005 12:47:50 +0200 (CEST)
> [EMAIL PROTECTED] (Derick Rethans) wrote:
>
> > On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
> >
> > > But I have some about what we will do in php 5.x (without
> > > unicode, namespace), and 6.0.
> > >
>
> 6.0 - to define, for now we have two candidates,
> unicode for sure, namespace to be discussed/approved/
> whatever
How 'bout PIMP for 6.0, Pierre? *hint hint* ;)
- David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.
On Tue, 9 Aug 2005 12:47:50 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
>
> > But I have some about what we will do in php 5.x (without
> > unicode, namespace), and 6.0.
> >
> > I like to see once that we clearly and loudly define what we
On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
> But I have some about what we will do in php 5.x (without unicode,
> namespace), and 6.0.
>
> I like to see once that we clearly and loudly define what we want
> in or not. So I may waste less time than before.
I see it as:
4.4 - no new features, no
On Tue, 09 Aug 2005 13:24:56 +0300
[EMAIL PROTECTED] (Pasha Zubkov) wrote:
> Alan Knowles wrote:
> > The basic point is that is_a() provided negative testing of
> > non-existant classes
> > if (!is_a($obj, "SomeRarelyUsedClass")) {
> >
> > instance_of does not, and can not, at present.
>
>
A minimum of respect does not cost anything. The author of this
patch invest a lot of time in it.
Oh well, one of the reasons why the patch for the parser won't be
available, no faster parser for PHP. Neither the other stuff I was
working on, will just use for in my own compiles.
A major
On Tue, 9 Aug 2005 12:03:28 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> On Tue, 9 Aug 2005, Weyert de Boer wrote:
>
> > >6.0 if the Namespaces patch makes it in, 5.5 with Unicode
> > >only? ;)
> >
> > Namespaces patch is a patch so it's fine for version 5.5, if
> > you would ask me.
Alan Knowles wrote:
> The basic point is that is_a() provided negative testing of non-existant
> classes
> if (!is_a($obj, "SomeRarelyUsedClass")) {
>
> instance_of does not, and can not, at present.
You can use `if (!($obj instanceof SomeRarelyUsedClass))` ;)
Why statement `$obj instanceo
Hi Stanislav Malyshev, you wrote:
> Now the only problem I see here is if you
> type Bar when you intended to type Baz - but I'm not sure this warrants
> the fatal error.
Yes, unit tests could catch such issues.
> MW>>There could be a flag to let instanceof *not* die -
> MW>>a little less generi
Hi
I'm not sure what you guys are discussing here, but it's definitely not
up to any non-contributor to decide which version number we pick. And
making it dependable on whether some patch goes in or not doesn't make
sense at all.
Such a kind way of response on your site, I won't even consid
MW>>to *load* a class for checking an object to be of a specific class
MW>>
MW>>- just because of the simple reason that the checked object can not
MW>> be of *that* class, because it doesn't exist.
I think, if we leave alone the implementation, there's nothing logically
wrong to return false if
On Tue, 9 Aug 2005 10:41:07 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> Now that we branched it's time to rename HEAD to something else
> than 5.1 in order to have different version numbers. Although the
> name PHP 5.5 was mentioned before, I do think we should call it
> PHP 6.0. As t
On Tue, 9 Aug 2005, Weyert de Boer wrote:
> >6.0 if the Namespaces patch makes it in, 5.5 with Unicode only? ;)
>
> Namespaces patch is a patch so it's fine for version 5.5, if you would
> ask me. I would see the unicode support as a bigger step forward.
I'm not sure what you guys are discussing
I was just kidding. I too consider Unicode support a very drastic change
that deserves a new major version number. I'd like to see Namespaces support
in by then, too, though. I really think PHP needs it. These two "features"
are the only things PHP needs desperately, but cannot deliver.
- David
On Tue, 9 Aug 2005 10:15:15 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> On Tue, 9 Aug 2005, Pierre-Alain Joye wrote:
>
> > > This technique is already frequently used to cope with lazy
> > > loaded code, which even with cached code compilers, is pretty
> > > damn efficient in a scrip
Hi
6.0 if the Namespaces patch makes it in, 5.5 with Unicode only? ;)
Namespaces patch is a patch so it's fine for version 5.5, if you would
ask me.
I would see the unicode support as a bigger step forward.
--
Yours,
Weyert de Boer ([EMAIL PROTECTED])
innerfuse*
http://www.innerfuse.biz/
6.0 if the Namespaces patch makes it in, 5.5 with Unicode only? ;)
- David
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 09, 2005 10:41 AM
> To: PHP Developers Mailing List
> Subject: [PHP-DEV] PHP 5.5 or 6.0
>
> Now that we branched it's
Derick Rethans schrieb:
> I do think we should call it PHP 6.0
+1
--
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 unsubscribe, visi
On Tue, 9 Aug 2005, Derick Rethans wrote:
Now that we branched it's time to rename HEAD to something else than 5.1
in order to have different version numbers. Although the name PHP 5.5
was mentioned before, I do think we should call it PHP 6.0. As the
Unicode support is quite a drastic change. G
1 - 100 of 108 matches
Mail list logo
