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
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
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)
=
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
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
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
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
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
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
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
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
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
>
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
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
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 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
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
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, 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
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
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
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
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
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
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 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
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:
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
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, 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
-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
- -
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
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
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)
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
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
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
37 matches
Mail list logo
