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
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 use PHP 5, then I have
t
In file "main/streams.c, function PHPAPI size_t _php_stream_read(php_stream
*stream, char *buf, size_t size TSRMLS_DC) is called when php script is trying
to connect and read from remote web server.
I have so far traced that it is calling
toread = stream->ops->read(stream, buf, size TSRMLS_CC)
Interesting question here: what about overloaded methods, especially
overloaded ctors in Calendar etc?
David
Am 16.07.2007 um 17:44 schrieb Stanislav Malyshev:
the same) in all languages, js, c# or php. His question being:
will it
be the same with this project?
Maybe not exactly the
I disagree with this view of the world.
It doesn't have to be a complete either/or decision and labeling
everything as a "bc hacks" decision is an inacurrate and populistic way
of building FUD.
There are clear things we want to change (like register_globals) because
we believe that ultimately they
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm eager to try this new feature our but I'm dependent on the win32
built from snaps which unfortunately currently doesn't build (the last
build was before the namespace commits).
It seems the other platforms currently don't build either.
thanks
- -
On 7/16/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> a) I was talking about namespace name "A_B" not class/function name.
_ is legal identifier character, so it would not be a good idea to use
it as a separator. :: on the other side is natural scope separator in
many languages. But I'm ra
a) I was talking about namespace name "A_B" not class/function name.
_ is legal identifier character, so it would not be a good idea to use
it as a separator. :: on the other side is natural scope separator in
many languages. But I'm rather reluctant to start the "my separator is
better than
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
the same) in all languages, js, c# or php. His question being: will it
be the same with this project?
Maybe not exactly the same, since even C, C++ and Java API differ
enough, but close to it - i.e. the API set would follow what ICU APIs have.
--
Stanislav Malyshev, Zend Software Architect
[EM
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
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 with a
few popular apps +
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
Please read about the decision done regarding this and why it was done
at: http://derickrethans.nl/files/meeting-notes.html#move-ereg-to-pecl
This is getting quite boring. You have had over 2 years to read about
this and complain..and this wasn't the first time with your usual
comment "will break
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
Hi,
On Mon, 16 Jul 2007 15:47:36 +0300, in php.internals
[EMAIL PROTECTED] (Jani Taskinen) wrote:
>Now only places using the POSIX regex functions (ext/ereg/ excluded) are
>ext/standard/browscap.c and ext/pgsql/pgsql.c.
>
>So what to do with these 2 places using the POSIX stuff? Convert them to
>
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.
So what to do with these 2 places using the POSIX stuff? Convert them to
use PCRE functions or enable PC
On 7/14/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> So (from another character-set-intricacy-challenged individual),
> would ICU it be analogous to the DOM functions for manipulating
> XML-like structures? (The methods parentNode(), childNodes(),
> appendNode(), etc. are all supposed to
Hi,
Lukas Kahwe Smith wrote:
can you gives us a clarification on the question on if ctype will
infact be deprecated in PHP6?
ctype is not UTF-16 aware and therefore won't work with PHP 6 unicode
strings. Instead of ctype there are functions offered by ICU which will
be available for PHP 6.
So
PHP 6 Bug Database summary - http://bugs.php.net
Num Status Summary (46 total including feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
27372 Verified parse error loadin
I totally lack the words to describe the awesomeness of this. Really,
really fantastic. At Agavi (http://www.agavi.org/), we've ported
parts of ICU (locale, calendar, date) to PHP and we're using it
together with CLDR data, but as you might imagine, it's awfully slow.
This new extension wil
Johannes Schlüter wrote:
Hi Lukas,
On Mon, 2007-07-16 at 08:48 +0200, Lukas Kahwe Smith wrote:
can you gives us a clarification on the question on if ctype will infact
be deprecated in PHP6?
ctype is not UTF-16 aware and therefore won't work with PHP 6 unicode
strings. Instead of ctype there
Hi Lukas,
On Mon, 2007-07-16 at 08:48 +0200, Lukas Kahwe Smith wrote:
> can you gives us a clarification on the question on if ctype will infact
> be deprecated in PHP6?
ctype is not UTF-16 aware and therefore won't work with PHP 6 unicode
strings. Instead of ctype there are functions offered by
As usual, consider Hans' opinion identical to mine ;) Nice job, can't
wait for it being out in the wild.
David
Am 15.07.2007 um 02:37 schrieb Hans Lellelid:
As someone that has long clamoured for namespaces in PHP, I have to
say
that this proposal by Dmitry is exactly what I & others have
PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (629 total including feature requests)
===[*Programming Data Structures]=
40496 Assigned Test bug35239.phpt still fails (works in PHP 5)
=
On Sun, 2007-07-15 at 19:06 -0700, Stanislav Malyshev wrote:
> >> Use any of the debuggers available to step into it and see which
> >> function is called.
> > Since PHP is invoked by Apache server, how can I hockup gcc with php ?
> > is there an easy way to do this ?
>
> easier way would be to
On 7/16/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> The other thing that bothers me is namespaces nesting. It was said
> that namespaces
> nesting is not supported. Then I'm missing a point in having namespace
> named "A::B".
The same reason some people write $a = f($z, $t) and some writ
37 matches
Mail list logo
