On Mon, July 30, 2007 2:22 am, Richard Lynch wrote:
> On Mon, July 16, 2007 7:47 am, Jani Taskinen wrote:
>> Now only places using the POSIX regex functions (ext/ereg/ excluded)
>> are
>> ext/standard/browscap.c and ext/pgsql/pgsql.c.
>
> For your review, my first patch (!) along with a php test ca
On Mon, July 16, 2007 7:47 am, Jani Taskinen wrote:
> Now only places using the POSIX regex functions (ext/ereg/ excluded)
> are
> ext/standard/browscap.c and ext/pgsql/pgsql.c.
For your review, my first patch (!) along with a php test case, of
course, in a URL/directory structure that should be f
On Mon, July 16, 2007 7:47 am, Jani Taskinen wrote:
> Now only places using the POSIX regex functions (ext/ereg/ excluded)
> are
> ext/standard/browscap.c and ext/pgsql/pgsql.c.
As you may know, I'm working on converting ext/pgsql/pgsql.c to use
PCRE instead of POSIX regex.
It's actually going f
Also I wonder how a unicode on/off switch will be handled on the
documentation side. It would add more permutations in the
documentation to have the switch. From my understanding the
situation is fairly non trivial already in how to handle all the
version dependent differences. Philipp, w
Jani Taskinen writes:
> On Thu, 2007-07-19 at 15:39 -0700, Andrei Zmievski wrote:
> > Python did go down that road, but take a look at Python 3000 effort
> > and you will see that what they are trying to do is exactly what we
> > have: native Unicode strings, without prefixes.
>
> So maybe we sh
On Fri, 2007-07-20 at 15:46 -0500, Richard Lynch wrote:
> u"stuff typed in unicode" to allow creation of Unicode strings in PHP5
> seems like a Good Idea to this naive reader, if it's easy enough to
> code that.
No, we can't introduce a unicode string type in PHP 5.
johannes
--
PHP Internals -
On Thu, July 19, 2007 8:29 am, Jani Taskinen wrote:
> On Thu, 2007-07-19 at 15:47 +0300, Tomas Kuliavas wrote:
>> > From the low end user perspective I think this would be great
>> from
>> > another POV. Let's imagine for a second that Wordpress will only
>> work
>> > with unicode semantics off
On Fri, July 20, 2007 3:07 am, Alexey Zakhlestin wrote:
> On 7/20/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
>> I think on Windows you can do something with the registry per-dir
>> too.
>> On unix there's no registry though. Maybe we need some generic
>> solution
>> to this (like for FastCGI
On Thu, July 19, 2007 7:52 pm, Stanislav Malyshev wrote:
>> Yeah I also like that casting better than the "u"
>
> It's different things. Casting means "create string as binary, then in
> runtime cast it to unicode", u"" means "this string is unicode".
Oh.
I think we're going to have to write some
On Thu, 2007-07-19 at 15:39 -0700, Andrei Zmievski wrote:
> Python did go down that road, but take a look at Python 3000 effort
> and you will see that what they are trying to do is exactly what we
> have: native Unicode strings, without prefixes.
So maybe we should learn from mistakes other h
On 7/20/07, Alexey Zakhlestin <[EMAIL PROTECTED]> wrote:
On 7/20/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> I think on Windows you can do something with the registry per-dir too.
> On unix there's no registry though. Maybe we need some generic solution
> to this (like for FastCGI users)?
On 7/20/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
I think on Windows you can do something with the registry per-dir too.
On unix there's no registry though. Maybe we need some generic solution
to this (like for FastCGI users)? Anybody has good ideas?
FastCGI users already can have their
On Wed, 18 Jul 2007, Andi Gutmans wrote:
> Functions would work properly with Unicode, but you would explicitly
> create Unicode strings e.g. u"foobar". This is not uncommon practice and
> many other languages actually go down this route incl. Python and
> various versions of C++ frameworks.
That
Am 19.07.2007, 14:27 Uhr, schrieb Keryx Web <[EMAIL PROTECTED]>:
> Zeev Suraski wrote:
>
> > Other than the theological views some people on this list have
> (either very pro-BC or anti-BC), what did keeping BC cost us?
>
> Hey that must be me he is talking about - as I am a real theologian!
>
>
David Coallier
Sent: Thursday, July 19, 2007 8:19 PM
To: Stanislav Malyshev
Cc: [EMAIL PROTECTED]; internals@lists.php.net
Subject: Re: [PHP-DEV] POSIX regex
On 7/19/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > Yeah I also like that casting better than the "u"
>
&g
On 7/19/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Yeah I also like that casting better than the "u"
It's different things. Casting means "create string as binary, then in
runtime cast it to unicode", u"" means "this string is unicode".
--
You are right that casting means string -> bi
Yeah I also like that casting better than the "u"
It's different things. Casting means "create string as binary, then in
runtime cast it to unicode", u"" means "this string is unicode".
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN:
ts.php.net
Subject: RE: [PHP-DEV] POSIX regex
I don't really know much about unicode, and to be honest, I don't really
know much about the internal workings of php.
But I assume that there are going to be different implementations of string
functions depending on whether the string is unicod
Scott
-Original Message-
From: Andrei Zmievski [mailto:[EMAIL PROTECTED]
Sent: Friday, 20 July 2007 9:36 AM
To: [EMAIL PROTECTED]
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] POSIX regex
On Jul 19, 2007, at 4:14 PM, <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
>
On Jul 19, 2007, at 4:14 PM, <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
I don't like the idea of having a "u" prefix for Unicode strings.
It may
improve performance, and give you some level of fine grain control,
but...
- It breaks your "keep php simple" policy by introducing a lot o
-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
Sent: Friday, 20 July 2007 8:47 AM
To: Andrei Zmievski
Cc: Andi Gutmans; Derick Rethans; Lukas Kahwe Smith; Ilia Alshanetsky;
[EMAIL PROTECTED]; internals@lists.php.net
Subject: Re: [PHP-DEV] POSIX regex
> Python did g
ndi Gutmans; Derick Rethans; Lukas Kahwe Smith; Ilia Alshanetsky;
[EMAIL PROTECTED]; internals@lists.php.net
Subject: Re: [PHP-DEV] POSIX regex
> Python did go down that road, but take a look at Python 3000 effort and
> you will see that what they are trying to do is exactly what we hav
Python did go down that road, but take a look at Python 3000 effort and
you will see that what they are trying to do is exactly what we have:
native Unicode strings, without prefixes.
Maybe still having u"" - that always produce unicode, regardless of
semantics - could be helpful...
--
Stani
Python did go down that road, but take a look at Python 3000 effort
and you will see that what they are trying to do is exactly what we
have: native Unicode strings, without prefixes.
-Andrei
On Jul 18, 2007, at 11:51 AM, Andi Gutmans wrote:
Functions would work properly with Unicode, but
On 7/19/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Too bad it only works for Apache module.. ;)
I think on Windows you can do something with the registry per-dir too.
On unix there's no registry though. Maybe we need some generic solution
to this (like for FastCGI users)? Anybody has go
Too bad it only works for Apache module.. ;)
I think on Windows you can do something with the registry per-dir too.
On unix there's no registry though. Maybe we need some generic solution
to this (like for FastCGI users)? Anybody has good ideas?
--
Stanislav Malyshev, Zend Software Architect
[
On Thu, 2007-07-19 at 15:47 +0300, Tomas Kuliavas wrote:
> > From the low end user perspective I think this would be great from
> > another POV. Let's imagine for a second that Wordpress will only work
> > with unicode semantics off and that phpBB will only work with the switch
> > "on". What if
On Thu, 2007-07-19 at 14:27 +0200, Keryx Web wrote:
> one *main* purpose and that is I am trying to remedy the extremely sad
> situation when it comes to books and other teaching material about PHP
> in Sweden. All books we have got by Swedish authors are so bad that I
> actively discourage peop
> From the low end user perspective I think this would be great from
> another POV. Let's imagine for a second that Wordpress will only work
> with unicode semantics off and that phpBB will only work with the switch
> "on". What if someone would want to run both on a shared server?
from httpd.c
Zeev Suraski wrote:
> Other than the theological views some people on this list have
(either very pro-BC or anti-BC), what did keeping BC cost us?
Hey that must be me he is talking about - as I am a real theologian!
So for a theologians 2c on Unicode:
1. Teaching unicode and PHP
As stated e
On Wed, July 18, 2007 3:04 am, Derick Rethans wrote:
> I hope you are not suggesting to port them to both modes? Why on earth
> should an application support both unicode=off and unicode=on? That's
> exactly the thing that some of us are so afraid of and want to prevent
> as this just annoys more a
Richard Lynch wrote:
Any gurus really offended by ereg can --disable-ereg or whatever it
is, no?
So in a dream world, Rasmus would have shipped all the features of PHP
42 as his first release.
In a slightly less dreamy, but still unrealistic world, we would have
infinite development resour
On Wed, July 18, 2007 10:45 am, Zeev Suraski wrote:
I also was thinking the other day, like Ze'ev, that PHP Devs aren't
really in touch with the unwashed masses of the userbase...
There are a zillion websites "out there" that run on shared hosts with
copy/pasted code and all these scripters will
On Wednesday 18 July 2007, Rasmus Lerdorf wrote:
> Second, from the user space PHP developers' perspective. There are two
> groups of those out there. There is the group that builds apps for
> controlled environments. Yahoo, Facebook, and the hundreds, if not
> thousands of smaller companies ou
On Tue, 17 Jul 2007 08:47:42 +0200, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> Larry Garfield wrote:
>> Non-core PHP developer speaking, so read with that in mind:
>>
>> One of the things that held back PHP 5 adoption for so long, IMO, is the
>> large
>> amount of FUD that surrounded it. E
gt; From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 18, 2007 1:07 AM
> To: Stas Malyshev
> Cc: Lukas Kahwe Smith; Andi Gutmans; Ilia Alshanetsky;
> [EMAIL PROTECTED]; internals@lists.php.net
> Subject: Re: [PHP-DEV] POSIX regex
>
> On Tue, 17 Jul 2007, St
On 7/18/07, Zeev Suraski <[EMAIL PROTECTED]> wrote:
Well I don't think it really diminishes, but I agree that 1+1 is
maybe 1.9 and not 2. On the other hand, if you remember that
perception is everything (or at least very important), 1+1 can easily
be perceived as 3, and in a negative sense.
E
At 04:47 18/07/2007, Lukas Kahwe Smith wrote:
Zeev Suraski wrote:
Finally, at the risk of sounding like a broken record, we always
need to remember that BC breakage accumulates, and it's not
binary. Every cleanup we do in PHP 6 will further slow migration,
and as Andi pointed out a few days
Johannes Schlüter wrote:
Ah, another thing kind of related to this thread: We really need a
proper way of having decisions declared as being made. Recently it
happened quite often that many developer's thought some decision was
made (for example from reading the Paris meeting notes) and then s
Pierre wrote:
On 7/18/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
Zeev Suraski wrote:
> Finally, at the risk of sounding like a broken record, we always
need to
> remember that BC breakage accumulates, and it's not binary. Every
> cleanup we do in PHP 6 will further slow migration, and
On 7/18/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
Zeev Suraski wrote:
> Finally, at the risk of sounding like a broken record, we always need to
> remember that BC breakage accumulates, and it's not binary. Every
> cleanup we do in PHP 6 will further slow migration, and as Andi pointed
>
Zeev Suraski wrote:
Finally, at the risk of sounding like a broken record, we always need to
remember that BC breakage accumulates, and it's not binary. Every
cleanup we do in PHP 6 will further slow migration, and as Andi pointed
out a few days ago, things don't look too well as it is.
Agr
Hi Zeev,
On Wed, 2007-07-18 at 01:58 -0700, Zeev Suraski wrote:
> >Regarding the unicode on/off modes, I don't think you put yourself in
> >the developer's view at all. Users are not going to be better of having
> >to deal with both modes.
>
> Well, I tend to agree with you that they shouldn't ha
On Wed, 2007-07-18 at 12:23 +0200, Gaetano Giunta wrote:
> Maybe the only solution is making it easier to run different versions
> of php in parallel?
It's already easy and possible. Please don't start that discussion nor
spread the fud that it isn't.
--Jani
--
PHP Internals - PHP Runtime Dev
On Wed, 18 Jul 2007, Zeev Suraski wrote:
...
You know what, I agree. I wrote something to that effect in my post
from a few minutes ago. The vast userbase is mostly comprised of
people we hardly even get to see.
Sorry to chime in on this already long thread with my -negative-
commit karma, but
On Wed, 2007-07-18 at 02:42 -0700, Rasmus Lerdorf wrote:
> What may be somewhat lost in all this, that I hope nobody here is
> forgetting, is that smooth Unicode support is really important. Being
Smooth it will be only if it's the only option. Otherwise it's just PITA
for both the camps. I'm all
Rasmus Lerdorf wrote:
Derick Rethans wrote:
Regarding the unicode on/off modes, I don't think you put yourself in
the developer's view at all. Users are not going to be better of having
to deal with both modes.
Have you guys really thought this through?
Let's look at this from two angles.
F
Rasmus Lerdorf wrote:
>
> Perhaps the real argument here is whether we should be doing Unicode at all?
I've watched these debate with tremendous interest. i18n is one of my
pure 'hobbies' (my 'clients' are all quite happy with ISO-8859-1, and
one of my backgrounds is WinNT where everything becam
Derick Rethans wrote:
> Regarding the unicode on/off modes, I don't think you put yourself in
> the developer's view at all. Users are not going to be better of having
> to deal with both modes.
Have you guys really thought this through?
Let's look at this from two angles.
First, from the our
At 01:20 18/07/2007, Derick Rethans wrote:
This sounds like a broken record, this sounds like a broken record, this
sounds like a broken record. I've heard this so many times now, it
get's boring.
I'm not surprised, but it doesn't change the fact that it's true, though.
No matter how many time
At 00:55 18/07/2007, Pierre wrote:
My answer to Andi was not only about ereg but php6 in general (the
unicode flag being a much more important problem that ereg, for
example).
I fully agree with you. Each individual here does not represent the
user base but only a relative small part.
However,
On Wed, 2007-07-18 at 10:20 +0200, Derick Rethans wrote:
> On Wed, 18 Jul 2007, Zeev Suraski wrote:
> > As for ereg - especially in light of the discontinuation of PHP 4 we
> > shouldn't even consider removing it in PHP 5.
>
> I don't think anybody wanted to remove it in PHP 5 - just make it
> p
On Wed, 18 Jul 2007, Zeev Suraski wrote:
> At 00:21 17/07/2007, Pierre wrote:
> >
> > On 7/16/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> > > I disagree with this view of the world.
> >
> > Well, we seem to all agree on this view, but let forget this
> > unsignificant fact :)
>
> I wanted to
On Tue, 17 Jul 2007, Lukas Kahwe Smith wrote:
> Andi Gutmans wrote:
>
> > There are clear things we want to change (like register_globals) because
> > we believe that ultimately they have a significant benefit to our users
> > with controllable downside (there is an easy one line workaround which
On Tue, 17 Jul 2007, Stanislav Malyshev wrote:
> > that would actually benefit quite a bit from unicode support, but I guess
> > you are talking about porting with unicode==off, right?
>
> unicode=off doesn't mean no unicode support, btw.
Of course that's what it means, as none of the string fun
On Tue, 17 Jul 2007, Andi Gutmans wrote:
> Hmm I don't quite understand what bad code vs. good code plays here.
> Wordpress is one of the most popular applications out there so it's got
> huge value to our community. I bet there's a huge amount of PHP
> applications who's source code is of the sam
On 7/18/07, Zeev Suraski <[EMAIL PROTECTED]> wrote:
Pierre,
I wanted to send my 2c even though I'm not really involved in
internals@ any longer - because in reality it doesn't really have
much to do with such decisions. internals@ makes decisions that
effect the entire PHP userbase.
We all ne
At 00:21 17/07/2007, Pierre wrote:
Hi Andi,
On 7/16/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
I disagree with this view of the world.
Well, we seem to all agree on this view, but let forget this
unsignificant fact :)
Pierre,
I wanted to send my 2c even though I'm not really involved in
On Tue, July 17, 2007 4:29 pm, Jani Taskinen wrote:
> Richard Lynch kirjoitti:
>> I took a brief look at the pgsql.c stuff, and it looks like it's all
>> fairly straight-forward to alter to PCRE instead of POSIX, and it's
>> all localized to this function:
>> http://lxr.php.net/ident?i=php_pgsql_co
Richard Lynch kirjoitti:
I took a brief look at the pgsql.c stuff, and it looks like it's all
fairly straight-forward to alter to PCRE instead of POSIX, and it's
all localized to this function:
http://lxr.php.net/ident?i=php_pgsql_convert_match
Am I under-estimating the problem?
Propably not.
On Mon, July 16, 2007 7:47 am, Jani Taskinen wrote:
> I have moved the POSIX regex dependant functions to ext/ereg/
> extension.
>
> Now only places using the POSIX regex functions (ext/ereg/ excluded)
> are
> ext/standard/browscap.c and ext/pgsql/pgsql.c.
I took a brief look at the pgsql.c stuff,
On 7/17/07, Tomas Kuliavas <[EMAIL PROTECTED]> wrote:
>> 50% increase sounds off base. But I did not bench php6 yet. When all
>> the new features are implemented, it will make more sense to work on
>> the performance problem. For now, it is simply premature.
>
> If Moore's law stands for the comi
Nitpicking, are we? :)
Tomas Kuliavas kirjoitti:
50% increase sounds off base. But I did not bench php6 yet. When all
the new features are implemented, it will make more sense to work on
the performance problem. For now, it is simply premature.
If Moore's law stands for the coming years, this a
>> 50% increase sounds off base. But I did not bench php6 yet. When all
>> the new features are implemented, it will make more sense to work on
>> the performance problem. For now, it is simply premature.
>
> If Moore's law stands for the coming years, this argument is moot anyway.
> By the time PH
Pierre kirjoitti:
50% increase sounds off base. But I did not bench php6 yet. When all
the new features are implemented, it will make more sense to work on
the performance problem. For now, it is simply premature.
If Moore's law stands for the coming years, this argument is moot anyway.
By the
that would actually benefit quite a bit from unicode support, but I
guess you are talking about porting with unicode==off, right?
unicode=off doesn't mean no unicode support, btw.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL
On 7/17/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
I thought you were retired at the time...
Other were not. Some other were not even present. And those who were
present seem to have different interpretations of the decisions. I
also have to say that this meeting was done when we were not actu
On 7/17/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
Hmm I don't quite understand what bad code vs. good code plays here.
Wordpress is one of the most popular applications out there so it's got
huge value to our community. I bet there's a huge amount of PHP
applications who's source code is of the
Andi Gutmans wrote:
Hmm I don't quite understand what bad code vs. good code plays here.
Wordpress is one of the most popular applications out there so it's got
huge value to our community. I bet there's a huge amount of PHP
applications who's source code is of the same quality or worse. Anyway,
I thought you were retired at the time...
> -Original Message-
> From: Jani Taskinen [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 17, 2007 7:37 AM
> To: Andi Gutmans
> Cc: internals@lists.php.net
> Subject: RE: [PHP-DEV] POSIX regex
>
> Just FYI: I did no
Andi Gutmans wrote:
Here's my proposed way of figuring how to make migration easier. Port
the following applications to PHP 6 and let's see what we can learn from
it:
- mediaWiki
- SugarCRM
- Drupal
- Wordpress
IIRC Wordpress is a good example of bad source code to fix. Drupal would
be a good
Tuesday, July 17, 2007 7:50 AM
> To: Andi Gutmans
> Cc: Ilia Alshanetsky; [EMAIL PROTECTED]; internals@lists.php.net
> Subject: Re: [PHP-DEV] POSIX regex
>
> Andi Gutmans wrote:
>
> > Here's my proposed way of figuring how to make migration
> easier. Port
&g
it works pretty well.
>
> Andi
>
> > -Original Message-
> > From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED]
> > Sent: Monday, July 16, 2007 11:40 PM
> > To: Andi Gutmans
> > Cc: Ilia Alshanetsky; [EMAIL PROTECTED]; internals@lists.php.net
> > Subj
s way and it works pretty well.
Andi
> -Original Message-
> From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 16, 2007 11:40 PM
> To: Andi Gutmans
> Cc: Ilia Alshanetsky; [EMAIL PROTECTED]; internals@lists.php.net
> Subject: Re: [PHP-DEV] POSIX regex
Hi Andi,
On 7/16/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
I disagree with this view of the world.
Well, we seem to all agree on this view, but let forget this
unsignificant fact :)
It doesn't have to be a complete either/or decision and labeling
everything as a "bc hacks" decision is an i
Larry Garfield wrote:
Non-core PHP developer speaking, so read with that in mind:
One of the things that held back PHP 5 adoption for so long, IMO, is the large
amount of FUD that surrounded it. Even now, 3 years after it was released, I
keep seeing the argument that "I can't drop PHP 4 and u
Andi Gutmans wrote:
There are clear things we want to change (like register_globals) because
we believe that ultimately they have a significant benefit to our users
with controllable downside (there is an easy one line workaround which
we can document for people to get their old apps to work). T
o just basing
> decisions on gut feelings. Maybe that kind of learning experience will
> proove me wrong (which may be so).
>
> Andi
>
> > -Original Message-
> > From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED]
> > Sent: Monday, July 16, 2007 7:25 AM
> &g
ns on gut feelings. Maybe that kind of learning experience will
proove me wrong (which may be so).
Andi
> -Original Message-
> From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 16, 2007 7:25 AM
> To: Andi Gutmans
> Cc: Ilia Alshanetsky; [EMAIL PROT
On 7/16/07, Jani Taskinen <[EMAIL PROTECTED]> wrote:
Thank you Lucas and Antony. Could not agree more..
But we all agree, don't we? :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 7/16/07, Jani Taskinen <[EMAIL PROTECTED]> wrote:
Thank you Lucas and Antony. Could not agree more..
On Mon, 2007-07-16 at 19:19 +0400, Antony Dovgal wrote:
> Thank you Lukas for expressing exactly my thoughts on this.
>
> On 16.07.2007 18:24, Lukas Kahwe Smith wrote:
> > Andi Gutmans wrote:
Thank you Lucas and Antony. Could not agree more..
On Mon, 2007-07-16 at 19:19 +0400, Antony Dovgal wrote:
> Thank you Lukas for expressing exactly my thoughts on this.
>
> On 16.07.2007 18:24, Lukas Kahwe Smith wrote:
> > Andi Gutmans wrote:
> >> Even in PHP 6 I am not sure it's a good idea. The
Thank you Lukas for expressing exactly my thoughts on this.
On 16.07.2007 18:24, Lukas Kahwe Smith wrote:
Andi Gutmans wrote:
Even in PHP 6 I am not sure it's a good idea. There are a huge amount of
apps that use them and it'll be very hard for people to upgrade.
Anyway, let's do some more rese
On Mon, 2007-07-16 at 15:22 +0100, Nuno Lopes wrote:
> PCRE has a POSIX API, so it is possible to use PCRE as a drop-in replacement
> for the engine behind ereg(). What I don't know is how compatible it is with
> the current engine. But I think it worth investigating.
Worked fine when I tested i
Ilia Alshanetsky wrote:
On 16-Jul-07, at 9:46 AM, Andi Gutmans wrote:
Why move it to PECL? I agree that PCRE is the preferred way but not
having ereg() will break a huge amount of applications for very little
gain.
I tend to agree, unless we provide wrappers via PCRE that emulate ereg
funct
Andi Gutmans wrote:
Even in PHP 6 I am not sure it's a good idea. There are a huge amount of
apps that use them and it'll be very hard for people to upgrade.
Anyway, let's do some more research on that once we get closer to PHP 6
and see what the migration path looks like. We'll have to check wit
PCRE has a POSIX API, so it is possible to use PCRE as a drop-in replacement
for the engine behind ereg(). What I don't know is how compatible it is with
the current engine. But I think it worth investigating.
Nuno
P.S.: this POSIX PCRE layer isn't currently bundled with PHP, because it
wasn
On Mon, 16 Jul 2007, Pierre wrote:
> On 7/16/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> > Even in PHP 6 I am not sure it's a good idea.
>
> As far as I know, Jani is referring to PHP6 only. And it was "decided"
> in the "php6 notes".
Unfortunately that is not true. It's only the title of the
s@lists.php.net
> Subject: Re: [PHP-DEV] POSIX regex
>
>
> On 16-Jul-07, at 9:46 AM, Andi Gutmans wrote:
>
> > Why move it to PECL? I agree that PCRE is the preferred way but not
> > having ereg() will break a huge amount of applications for
> very little
> &g
On Mon, 16 Jul 2007, Andi Gutmans wrote:
> Even in PHP 6 I am not sure it's a good idea. There are a huge amount of
> apps that use them and it'll be very hard for people to upgrade.
Their apps are breaking anyway and three regex engines doesn't make
sense.
Derick
--
Derick Rethans
http://de
On 7/16/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
Even in PHP 6 I am not sure it's a good idea.
As far as I know, Jani is referring to PHP6 only. And it was "decided"
in the "php6 notes".
I'm in favour to remove ereg in php6, and the sooner we decide the
better.Users will know about this cha
gt;
> Andi
>
> > -Original Message-
> > From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED]
> > Sent: Monday, July 16, 2007 6:48 AM
> > To: Andi Gutmans
> > Cc: [EMAIL PROTECTED]; internals@lists.php.net
> > Subject: Re: [PHP-DEV] POSIX regex
> >
&g
On 16-Jul-07, at 9:46 AM, Andi Gutmans wrote:
Why move it to PECL? I agree that PCRE is the preferred way but not
having ereg() will break a huge amount of applications for very little
gain.
I tend to agree, unless we provide wrappers via PCRE that emulate
ereg functionality I don't think w
Why move it to PECL? I agree that PCRE is the preferred way but not
having ereg() will break a huge amount of applications for very little
gain.
We might possibly want to consider disabling by default but not having
it in the default package doesn't make real sense.
Trying to do browscap.c and pg
94 matches
Mail list logo
