On Wed, Jul 29, 2009 at 23:33, Alban wrote:
> Le Fri, 24 Jul 2009 15:23:21 +0200, user a écrit :
>
>> I published a (work in progress) RFC today about replacing certain
>> errors with exceptions. I know that there already was something similiar
>> on the php6dev blog, but this is not completly the
>
> What do you think about the possibility to support ArrayObject
> instances in array_* functions?
> If you all agreed on this, I can definately help to complete the
> patch, but I need some initial guidance to finish at least the first
> function.
>
I think it's a marvelous idea :)
I'm attachi
2009/7/30 David Coallier
> >
> > What do you think about the possibility to support ArrayObject
> > instances in array_* functions?
> > If you all agreed on this, I can definately help to complete the
> > patch, but I need some initial guidance to finish at least the first
> > function.
> >
>
> I
2009/7/26 Moriyoshi Koizumi :
> - mb_ereg_search(), mb_ereg_search_getpos(), mb_ereg_search_getregs(),
> mb_ereg_search_init(), mb_ereg_search_pos(), mb_ereg_search_regs() and
> mb_ereg_search_setpos()
> I rarely heard a script that actively uses these functions. They
> involve an internal sta
> Hi there,
>
> I almost finished an alternative implementation of mbstring that uses
> ICU instead of the exotic libmbfl in hope of replacing the current one
> for 5.4 (and possibly, 6.0.)
>
> Although there are admittingly some known incompatibilities that need
> extra libraries to resolve them
On Thu, Jul 30, 2009 at 3:05 PM, Niel Archer wrote:
>> Implemented functions:
>>
>> - mb_ereg()
>> - mb_ereg_replace()
>
> as ereg functions are deprecated in 5.3, are these still needed?
these have nothing in common with "those" ereg functions. these are
based on onuguruma regex library
http://w
On Thu, 2009-07-30 at 00:08 -0300, Guilherme Blanco wrote:
> What do you think about the possibility to support ArrayObject
> instances in array_* functions?
> If you all agreed on this, I can definately help to complete the
> patch, but I need some initial guidance to finish at least the first
> f
2009/7/30 Johannes Schlüter :
> On Thu, 2009-07-30 at 00:08 -0300, Guilherme Blanco wrote:
>> What do you think about the possibility to support ArrayObject
>> instances in array_* functions?
>> If you all agreed on this, I can definately help to complete the
>> patch, but I need some initial guida
On Jul 30, 2009, at 7:12 AM, Alexey Zakhlestin wrote:
Implemented functions:
- mb_ereg()
- mb_ereg_replace()
as ereg functions are deprecated in 5.3, are these still needed?
these have nothing in common with "those" ereg functions. these are
based on onuguruma regex library
http://www.geocitie
I'm trying to avoid a "globally solution" on first instance to avoid a
great impact on language.
If you wanna ask me what's the global solution, I'll suggest a
Collection like implementation for all array functions.
http://en.wikipedia.org/wiki/Collection_%28computing%29
http://trac.doctrine-proje
2009/7/30 Alexey Zakhlestin
> 2009/7/30 Johannes Schlüter :
> > On Thu, 2009-07-30 at 00:08 -0300, Guilherme Blanco wrote:
> >> What do you think about the possibility to support ArrayObject
> >> instances in array_* functions?
> >> If you all agreed on this, I can definately help to complete the
On Thu, 2009-07-30 at 11:42 -0300, Guilherme Blanco wrote:
> I'm trying to avoid a "globally solution" on first instance to avoid a
> great impact on language.
> If you wanna ask me what's the global solution, I'll suggest a
> Collection like implementation for all array functions.
Define "all arr
On Jul 30, 2009, at 11:27 AM, Stefan Walk wrote:
and that there's nothing you can do with Oniguruma that you can't
also practically do with PCRE (to the best of my knowledge),
http://www.geocities.jp/kosako3/oniguruma/doc/RE.txt - Paragraph 8,
example 2 - specifying the nest level for subrouti
Howdy,
In response to Bug #48911(http://bugs.php.net/bug.php?id=48911), revision
286468 adds SAPI_API to
int php_embed_init(int argc, char **argv PTSRMLS_DC);
void php_embed_shutdown(TSRMLS_D);
extern sapi_module_struct php_embed_module;
Which breaks building the php5embed on Windows.
Until now I tried to find the easiest possible solution.
Currently we have two paths to chose:
1- A class that implements ArrayAccess must be useable everywhere an
"array" is useable;
2- ArrayAccess needs to be expanded with methods for all the array
functions and ArrayObject needs to implement th
Hi,
I like this idea very much, too but I do see the problems in doing it
correctly.
From my point of view the problem looks as follows:
PHP arrays are a wonderful universal construct but it is problematic
to use them in scenarios where you dont want to bind directly to the
single, avail
Hi!
Aren't there any interests on this? If you think PHP 6 is gonna cover
all of the functionality that allegedly-cruft mbstring currently
provides, that is almost wrong :-p
Could you please explain why PHP6 doesn't provide what mbstring is
doing? I.e, let's go over the functions:
mb_parse_
On Thu, Jul 30, 2009 at 10:48:49AM +0200, Hannes Magnusson wrote:
> No PHP warnings at all.
>
>
> Again. The examples you are looking for are network issues with
> fopen(), file_get_contents() and such things.
>
> -Hannes
Hannes, these are actually the ones I had in mind when I sent my last
ema
Hi!
1- A class that implements ArrayAccess must be useable everywhere an
"array" is useable;
The problem is that many functions dealing with arrays do not make sense
with generic object. For others, it may make sense in theory, but not be
practical - e.g., suppose you have ArrayAccess object
On Thu, Jul 30, 2009 at 20:28, Joey Smith wrote:
> However, now that it's come up, I'm wondering what the costs/risks are
> of setting libxml_use_internal_errors() on by default?
I don't think thats a good idea.
People are used to getting a warning when stuff fails, and suppressing
them all of the
Hi Stan,
I don't really know which implementation is preferrable.
I just dropped the idea here first. Once decided, I can write a detailed RFC.
With some initial help, I can work on the patch to support it. I'm not
expert in internals, so some help will be surely needed.
I'm totally opened to su
Hannes Magnusson wrote:
> On Thu, Jul 30, 2009 at 20:28, Joey Smith wrote:
>> However, now that it's come up, I'm wondering what the costs/risks are
>> of setting libxml_use_internal_errors() on by default?
>
> I don't think thats a good idea.
> People are used to getting a warning when stuff fail
Greetings list,
I've modified fopen_wrappers.c to add some custom security checks for
our environment.
Part of the check requires obtaining the DocumentRoot.
The modification begins at line 115 where the DocumentRoot is found:
// Document root from Zend (pointer to pointer)
zval **document_
>Le Thu, 30 Jul 2009 10:48:49 +0200, Hannes Magnusson a écrit :
>
> Are you intentionally ignoring what I've said previously in the thread?
> Please stop using SimpleXML as an example. You do not need @. libxml_use_internal_errors(true);
> [...]
>
> Again. The examples you are looking for are ne
24 matches
Mail list logo
