> I think PHP 6.0 provides an excellent opportunity to rectify a huge number
> of frustrating inconsistencies; it would be a shame not to make the most of
> this.
>
>
>
> The two biggest inconsistencies raised by users and "language comparison"
> groups are a) function argument order, and b) fun
> >> This is the first one that comes to my mind:
> >>
> >> int strpos (string haystack, mixed needle [, int offset])
> >>
> > And this is why they're inconsistent to begin with. When I look at
> > strpos() I
> > think: strchr(char *, int) So the parameter ordering does make sense the
If apc comes bundled then it includes apc_store() and apc_fetch() this
is pretty much $_MEMORY with a few tweaks.
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Aug 13, 2005, at 5:37 PM, Jani Taskinen wrote:
-Inf
We're talking about cleaning up legacy stuff, not creating
new, aren't we? :)
And iirc, using [] for strings has been "deprecated" for ages
now.
Not really. [] and {} compile to exactly the same thing, actually.
-Andre
On Sun, 2005-08-14 at 00:28, Sara Golemon wrote:
> >> PHP_FUNCTION(strpos)
> >> {
> >> ...
> >> /* Swap needle and haystack if they appear to be backwards */
> >> if (needle_len > haystack_len) {
> >> char *t; int t_len;
> >> t = needle; needle = haystack; haystack = t;
> >>
So, you'd rather have PHP users gain some speed at the expense of
having to check for surrogates everywhere?
-Andrei
On Aug 13, 2005, at 5:23 AM, Derick Rethans wrote:
On Sat, 13 Aug 2005, Ilia Alshanetsky wrote:
I thought we've discussed making one access code-units and the other
code-p
zend_unicode.c is the place for it, IMHO.
-Andrei
On Aug 13, 2005, at 6:52 AM, Wez Furlong wrote:
A number of extensions/functions (strangely, most of the things I work
on :-) will need to be able to convert between unicode and arbitrary
encodings. It makes a lot of sense to keep some kind o
No.
http://www.unicode.org/faq/basic_q.html#23
-Andrei
On Aug 13, 2005, at 1:29 PM, Wez Furlong wrote:
And isn't UTF16 === UCS2 ?
--Wez.
On 8/13/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
"Wez Furlong" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Umm, don't we use UC
On Aug 12, 2005, at 3:18 PM, l0t3k wrote:
my uneasiness with this is that if the macro is mandatory, it (to me)
implies, from a usability point of view, that
that zend_parse_parameters, instanceof_functions etc are now "broken".
z_p_p, for example, was a god-send, because it took care of all the
"Jani Taskinen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Sat, 13 Aug 2005, Marco Tabini wrote:
>
>> Or maybe so that you don't have to look at the manual fifteen times a
>> minute
>> so that you can remember whether the needle goes before the haystack in a
>> particular fu
PHP_FUNCTION(strpos)
{
...
/* Swap needle and haystack if they appear to be backwards */
if (needle_len > haystack_len) {
char *t; int t_len;
t = needle; needle = haystack; haystack = t;
t_len = needle_len; needle_len = haystack_len; haystack_len =
t_len;
}
..
"Christian Schneider" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> foo(id: 64738, name: "foo");
Oh, I love that syntax ;)
Ron
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sat, 2005-08-13 at 23:53, Sara Golemon wrote:
> > I really doubt this will change.
> > It would be a *huge* mess in the docs
> > and peoples scripts and brains
> > if we did change it--it wouldn't really
> > win anyone anything:
> >
> At the risk of someone taking this as a worthwhile idea:
>
>
I really doubt this will change.
It would be a *huge* mess in the docs
and peoples scripts and brains
if we did change it--it wouldn't really
win anyone anything:
At the risk of someone taking this as a worthwhile idea:
PHP_FUNCTION(strpos)
{
...
/* Swap needle and haystack if they appear to
Yeah. It's propably best to leave these alone. :)
--Jani
On Sat, 13 Aug 2005, Wez Furlong wrote:
I really doubt this will change.
It would be a *huge* mess in the docs and peoples scripts and brains
if we did change it--it wouldn't really win anyone anything:
function portable_strpo
I really doubt this will change.
It would be a *huge* mess in the docs and peoples scripts and brains
if we did change it--it wouldn't really win anyone anything:
function portable_strpos($needle, $haystack) {
if (version_compare(phpversion(), "6.0"))) {
return strpos($needle, $haystack);
On Aug 13, 2005, at 6:50 PM, Jani Taskinen wrote:
On Sat, 13 Aug 2005, Sara Golemon wrote:
This is the first one that comes to my mind:
int strpos (string haystack, mixed needle [, int offset])
And this is why they're inconsistent to begin with. When I look
at strpos() I think: strc
On Sat, 13 Aug 2005, Sara Golemon wrote:
set short_open_tags to off in any sample php.ini we ship.
Ah yes, that reminds me:
17. Nuke every "alternative" open tag and only have
Agreed (though not so much nuke as default to off).
Whenever open tags comes up, I'll toss
On Sat, 13 Aug 2005, Sara Golemon wrote:
This is the first one that comes to my mind:
int strpos (string haystack, mixed needle [, int offset])
And this is why they're inconsistent to begin with. When I look at strpos() I
think: strchr(char *, int) So the parameter ordering does
set short_open_tags to off in any sample php.ini we ship.
Ah yes, that reminds me:
17. Nuke every "alternative" open tag and only have
Agreed (though not so much nuke as default to off).
Whenever open tags comes up, I'll toss
I'd go with zend_unicode.c as you can disable ext/unicode.
--Jani
On Sat, 13 Aug 2005, Wez Furlong wrote:
A number of extensions/functions (strangely, most of the things I work
on :-) will need to be able to convert between unicode and arbitrary
encodings. It makes a lot of sense to
This is the first one that comes to my mind:
int strpos (string haystack, mixed needle [, int offset])
And this is why they're inconsistent to begin with. When I look at strpos()
I think: strchr(char *, int) So the parameter ordering does make sense
there (to me).
-Sara
--
PHP
On Sat, 13 Aug 2005, George Schlossnagle wrote:
Maybe this could be something that ext/session could provide.
I sure can find some uses for a 'global session'.
That seems like a reasonable to go. I question it's utility a bit - how often
is this really useful? For large objects (lik
Hello Emil,
Sunday, August 14, 2005, 12:49:46 AM, you wrote:
> Talking about type hinting. It would be nice to be able to declare
> variables as a certain type once and for all (like c, although
> optional). I don't if this has been discussed and dismissed before,
> and if that is the case, pleas
Hello Joseph,
Sunday, August 14, 2005, 12:31:42 AM, you wrote:
> I would like to see the Type Hinting expanded in PHP 6. In 5 now you can do
> class Test {
> public function testDatabase( Database $db ) {
> }
> }
> what if i wanted to make sure it was a String, Integer, Boolean, Float,
> etc
Hello Jani,
Sunday, August 14, 2005, 2:37:36 AM, you wrote:
> On Fri, 12 Aug 2005, Andrei Zmievski wrote:
>> We did, but we never arrived at consensus. I don't really see a good reason
>> for giving people access to code-units with such a low-level operator. If we
>> fix it, I'd rather fix it so
On Sat, 13 Aug 2005, Lukas Smith wrote:
Ron Korving wrote:
16. Support for
that reminds me:
set short_open_tags to off in any sample php.ini we ship.
Ah yes, that reminds me:
17. Nuke every "alternative" open tag and only have http://www.php.net/unsub.php
On Aug 13, 2005, at 9:06 PM, Jani Taskinen wrote:
On Sat, 13 Aug 2005, George Schlossnagle wrote:
On Aug 13, 2005, at 5:08 AM, Ondrej Ivani wrote:
9. Shared memory storage for variables with transparent access.
(superglobal array?)
-1. This is hard to make consistent across all plat
On Sat, 13 Aug 2005, George Schlossnagle wrote:
On Aug 13, 2005, at 5:08 AM, Ondrej Ivani wrote:
9. Shared memory storage for variables with transparent access. (superglobal
array?)
-1. This is hard to make consistent across all platforms, and will break
instantly when you go past 1 mach
Hey Jani stop this, there was never a consensus on this kind of changes,
and there never will be because to BC break is so huge it hurts.
Edin
Jani Taskinen wrote:
sniper Sat Aug 13 20:46:53 2005 EDT
Modified files:
/php-src/ext/wddx php_wddx.h wddx.c
Log:
-
On Sat, 13 Aug 2005, Lukas Smith wrote:
Xuefer wrote:
possibly make a internal or loadable "argument reposition table", enabled
with:
declare(fix_function_argument_position);
fix at compile time, no performance lost on runtime.
but might confuse the debuger if the origin position in source is
On Sat, 13 Aug 2005, Marco Tabini wrote:
Or maybe so that you don't have to look at the manual fifteen times a minute
so that you can remember whether the needle goes before the haystack in a
particular function or not.
I'm all for making this consistent all around.
Best way to get thi
On Sat, 13 Aug 2005, David Zülke wrote:
10. namespace support (we are telling everyone php is ready for the big
soup. In those scenarios you often find big teams and any help allowing
things like dedicated responisbilities and preventing communication
problems is more then welcome.)
-1 before,
On Fri, 12 Aug 2005, Andrei Zmievski wrote:
We did, but we never arrived at consensus. I don't really see a good reason
for giving people access to code-units with such a low-level operator. If we
fix it, I'd rather fix it so that [] only works on arrays, and {} on strings,
+100
with s
Christian Schneider wrote:
What I don't like about Python at all is that AFAIK you can't call a
method with parameters not declared in the function definition.
Oops, Python does allow this with a *parameter or **parameter. Missed
that part when reading the specs :-)
- Chris
--
PHP Internals
George Schlossnagle wrote:
Huh? Perl doesn't have true support for this anyway, just a simpler
syntax for hashrefs. If you want Perlish named params this is 100%
identical to doing
foo(array('id' => 42, 'name' => 'foo'));
If you are using this a lot then syntactic sugar does make a differ
i agree with the last post, it would be nice for PHP to be a weakly typed
language but allow for the user to program strongly typed if they want to
such as the above suggestion of having the option to declare the type for a
variable.
--
Joseph Crawford Jr.
Codebowl Solutions, Inc.
1-802-671-2
Talking about type hinting. It would be nice to be able to declare
variables as a certain type once and for all (like c, although
optional). I don't if this has been discussed and dismissed before,
and if that is the case, please don't kill me. You're just
brainstorming anyway, right? :)
Emil
--
I would like to see the Type Hinting expanded in PHP 6. In 5 now you can do
class Test {
public function testDatabase( Database $db ) {
}
}
what if i wanted to make sure it was a String, Integer, Boolean, Float,
etc.. i would like to see that added to the type hinting ;)
--
Joseph Crawford J
On Aug 13, 2005, at 5:57 PM, Andrey Hristov wrote:
George Schlossnagle wrote:
On Aug 13, 2005, at 5:49 PM, Andrey Hristov wrote:
George Schlossnagle wrote:
On Aug 13, 2005, at 11:46 AM, Matthew Weier O'Phinney wrote:
* Christian Schneider <[EMAIL PROTECTED]> :
9. Named parameters.
George Schlossnagle wrote:
On Aug 13, 2005, at 5:49 PM, Andrey Hristov wrote:
George Schlossnagle wrote:
On Aug 13, 2005, at 11:46 AM, Matthew Weier O'Phinney wrote:
* Christian Schneider <[EMAIL PROTECTED]> :
9. Named parameters. Preferred way would be via array()-less array
collation
On Aug 13, 2005, at 5:49 PM, Andrey Hristov wrote:
George Schlossnagle wrote:
On Aug 13, 2005, at 11:46 AM, Matthew Weier O'Phinney wrote:
* Christian Schneider <[EMAIL PROTECTED]> :
9. Named parameters. Preferred way would be via array()-less array
collation as we are already using thi
George Schlossnagle wrote:
On Aug 13, 2005, at 11:46 AM, Matthew Weier O'Phinney wrote:
* Christian Schneider <[EMAIL PROTECTED]> :
9. Named parameters. Preferred way would be via array()-less array
collation as we are already using this in our production system ;-) :
foo('id' => 42, 'name'
On Aug 13, 2005, at 11:46 AM, Matthew Weier O'Phinney wrote:
* Christian Schneider <[EMAIL PROTECTED]> :
9. Named parameters. Preferred way would be via array()-less array
collation as we are already using this in our production system ;-) :
foo('id' => 42, 'name' => "foo");
+1 -- this is
Just my $0.02,
for the MS compilers wchar_t is 2 bytes while for gcc it is 4.
Andrey
Wez Furlong wrote:
"the fundamental representation of text in Windows NT-based operating
systems is UTF-16, and the WCHAR data type is a UTF-16 code unit"
So, it looks like we don't need to do anything speci
for what its worth - brilliant :-)
aftering reading the remarks about perl6 (love the idea of
you guys winning that 'race' :-) I did a little reading, seems
perl6 is aimed to target Parrot... I remember there was discussion
about this for php, don't know if the idea died a lonely death or
was jus
On Aug 13, 2005, at 3:21 PM, Derick Rethans wrote:
On Sat, 13 Aug 2005, George Schlossnagle wrote:
Good. That function would be evil (imho). Given that you can't
access
super-globals as variable-variables, I think that having to really
get at
_RAW_GET[] will make it much more transpare
Ron Korving wrote:
16. Support for
that reminds me:
set short_open_tags to off in any sample php.ini we ship.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
On Fri, 12 Aug 2005 10:48:20 -0700, in php.internals
[EMAIL PROTECTED] (Rasmus Lerdorf) wrote:
>Since we are breaking a lot of stuff in 6.0, at least with
>Unicode_semantics=On I am wondering if it may not be time to break some
>more stuff and do a bit of spring cleaning. It would mean many
"the fundamental representation of text in Windows NT-based operating
systems is UTF-16, and the WCHAR data type is a UTF-16 code unit"
So, it looks like we don't need to do anything special.
--Wez.
On 8/13/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Wez,
>
> UCS2 is limited to the repre
Wez,
UCS2 is limited to the representing characters within the BMP ( 1 code-unit
== 1 code-point)
UTF16 uses surrogates to address characters beyond the BMP (so a code-point
may be represented by 2 code-units)
clayton
"Wez Furlong" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
http://www.unicode.org/faq/basic_q.html#23
> -Original Message-
> From: Wez Furlong [mailto:[EMAIL PROTECTED]
> Sent: Saturday, August 13, 2005 10:30 PM
> To: [EMAIL PROTECTED]
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: php-src /ext/com_dotnet com_handlers.c
> com_variant.
And isn't UTF16 === UCS2 ?
--Wez.
On 8/13/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> "Wez Furlong" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> Umm, don't we use UCS2 internally?
>
> actually ICU is UTF16...
>
> l0t3k
>
>
> --Wez.
>
> On 8/13/05, [EMAIL PROTECTED]
"Wez Furlong" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Umm, don't we use UCS2 internally?
actually ICU is UTF16...
l0t3k
--Wez.
On 8/13/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Wez,
>
> > + case IS_UNICODE:
> > + V_VT(v) = VT_BSTR;
> > + V_BSTR(v) = SysAllocString
Umm, don't we use UCS2 internally?
--Wez.
On 8/13/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Wez,
>
> > + case IS_UNICODE:
> > + V_VT(v) = VT_BSTR;
> > + V_BSTR(v) = SysAllocString(Z_USTRVAL_P(z));
> > + break;
>
> my understanding is that Win32 uses UCS2, so do we need to account for
>
Derick,
That would not be much different then someone doing
foreach (array_keys($_GET) $v) $_GET[$v] = get_raw(GET, $v);
If anything locating RAW super-global would be easier, making auditing
coding reliant on it a bit simpler.
IMHO.
Derick Rethans wrote:
> On Sat, 13 Aug 2005, George Schlossna
But then everybody will just start using $_RAW_GET instead of $_GET.
What will that solve?
This was one of my concerns.
$_RAW_* is easy to grep for, though.
Sure, it can still be abused, but it'll be a lot easier to see WHERE
it's being abused. Currently, a grep for $_GET will return a large
Wez,
> + case IS_UNICODE:
> + V_VT(v) = VT_BSTR;
> + V_BSTR(v) = SysAllocString(Z_USTRVAL_P(z));
> + break;
my understanding is that Win32 uses UCS2, so do we need to account for
surrogates ?
l0t3k
""Wez Furlong"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> wez Sat Aug 13 15:
On Sat, 13 Aug 2005, George Schlossnagle wrote:
> Good. That function would be evil (imho). Given that you can't access
> super-globals as variable-variables, I think that having to really get at
> _RAW_GET[] will make it much more transparent when an application is using
> unfiltered data.
Bu
Wez,
zend_unicode.c may be a good bet, since the engine has to deal with
various encodings anyway (script, output, runtime)
clayton
"Wez Furlong" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Since this cache needs to always be present (to avoid crazy
conditional compilation) w
I am a bit reluctant to remove the old "functionality" outright, hence
the optional flag. Either way it seems better then what we've got right now.
Ilia
Stefan Esser wrote:
> Hello Ilia,
>
> if you look at the implementation of header() you will realise that
> sending multiple headers is actuall
Xuefer wrote:
possibly make a internal or loadable "argument reposition table", enabled with:
declare(fix_function_argument_position);
fix at compile time, no performance lost on runtime.
but might confuse the debuger if the origin position in source is
forget after compile
As I suggested by u
Hello Ilia,
if you look at the implementation of header() you will realise that
sending multiple headers is actually already abusing how it was designed
to work. Because the internal checks for double headers etc. do not work
at all when you send multiple headers.
Stefan
--
PHP Internals -
Perhaps the named parameters could even be constant-like?
How would this syntax be?
foo(id => 42, name => "foo");
Ron
"Matthew Weier O'Phinney" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> * Christian Schneider <[EMAIL PROTECTED]> :
> > 9. Named parameters. Preferred way would
How about we do this:
Add a 3rd optional param to header(), if it is unset we remove
everything from a header that contains \r\n or \n after those chars.
However if the developer feels the need to send multiple headers or what
not they can pass 3rd arg as TRUE and "restore" the functionality.
Ilia
If all you are doing is allowing a colon in the name and renaming all
the functions from str_foo to str:foo, I see this as complete pointless,
only increasing the wtf factor. And requiring everyone to rewrite their
scripts.
Ilia
Jessie Hernandez wrote:
> Hi Ilia,
>
> While it really doesn't matt
* Christian Schneider <[EMAIL PROTECTED]> :
> 9. Named parameters. Preferred way would be via array()-less array
> collation as we are already using this in our production system ;-) :
> foo('id' => 42, 'name' => "foo");
+1 -- this is one of the biggest things I miss coming from perl to PHP.
-
Hi Ilia,
While it really doesn't matter to me if functions are namespaced or not, or
even if functions are allowed inside namespaces, I just want to clarify
that only one hash table lookup would be done (as I said in my previous
post, this change was very simple, but all it did was allow the use o
+1 for namespaces
+1 for making current functions into namespaces
+1 for removing register_globals
--
Joseph Crawford Jr.
Codebowl Solutions, Inc.
1-802-671-2021
[EMAIL PROTECTED]
On 8/13/05, Marco Tabini <[EMAIL PROTECTED]> wrote:
>
> On 8/13/05 2:25 AM, "Ilia Alshanetsky" <[EMAIL PROTECTED]> wrote:
>
> > Why would I need name spaces for basic functions, just so that I need to
> > rename all my code to use str:replace rather then str_replace and
> > perform 2 hash table l
On Aug 13, 2005, at 8:19 AM, Derick Rethans wrote:
On Fri, 12 Aug 2005, steve roussey wrote:
4. Include an opcode cache by default. A lot of work has gone into
pecl/apc recently, but I am not hung up on which one goes in.
I have no karma to +1, but would if I could. It would be wonder
On Aug 13, 2005, at 8:14 AM, Derick Rethans wrote:
On Fri, 12 Aug 2005, George Schlossnagle wrote:
I wrote up the following spec for this extension:
http://files.derickrethans.nl/filter_extension.html
Where's the part about an application swapping back for the raw
arrays (as
opposed to
On Aug 13, 2005, at 5:08 AM, Ondrej Ivanič wrote:
9. Shared memory storage for variables with transparent access.
(superglobal array?)
-1. This is hard to make consistent across all platforms, and will
break instantly when you go past 1 machine, making it confusing and
of marginal usag
On Aug 13, 2005, at 2:29 AM, Ilia Alshanetsky wrote:
Marcus Boerger wrote:
9. __toString) everywhere, but i already said i'll take care of
that unless
i am being held back. So now go for that or live with the fact
that php is
meant to generate html pages which is text output. Thus sooner o
Hello internals,
Saturday, August 13, 2005, 2:58:26 PM, you wrote:
> Hello Derick,
> Saturday, August 13, 2005, 2:17:52 PM, you wrote:
>> On Fri, 12 Aug 2005, Sara Golemon wrote:
>>> > 7. Make identifiers case-sensitive
>>> >
>>> Or perhaps optionally case sensitive? I dunno, I've made my pea
On Sat, 13 Aug 2005 14:17:52 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> On Fri, 12 Aug 2005, Sara Golemon wrote:
>
> > > 7. Make identifiers case-sensitive
> > >
> > Or perhaps optionally case sensitive? I dunno, I've made my
> > peace with PHP being (mostly) case-insensitive.
>
>
On Fri, 12 Aug 2005 15:03:36 -0400
[EMAIL PROTECTED] (Ilia Alshanetsky) wrote:
> > I have a #9 to share, too:
> > Assuming that PHP 6.0 will also have namespaces support (which
> > would be cool), it might make sense to move all internal
> > functions to use namespaces (if they support functions s
A number of extensions/functions (strangely, most of the things I work
on :-) will need to be able to convert between unicode and arbitrary
encodings. It makes a lot of sense to keep some kind of per-request
cache (of limited length) to avoid having to load and unload the
conversion table on each
On Fri, 12 Aug 2005 20:19:04 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> On Fri, 12 Aug 2005, George Schlossnagle wrote:
>
> > > 3. Add input filter extension which will include a mechanism
> > > for application developers to very easily turn it off which
> > > would swap the raw GPC
Lukas Smith wrote:
Speaking of *kit .. how about sandboxing or some sort of taint model.
i'd beg for that.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christian Schneider wrote:
Rasmus Lerdorf wrote:
4. Include an opcode cache by default. A lot of work has gone into
pecl/apc recently, but I am not hung up on which one goes in.
Big +1
9. Named parameters. Preferred way would be via array()-less array
collation as we are already using
Hello Derick,
Saturday, August 13, 2005, 2:17:52 PM, you wrote:
> On Fri, 12 Aug 2005, Sara Golemon wrote:
>> > 7. Make identifiers case-sensitive
>> >
>> Or perhaps optionally case sensitive? I dunno, I've made my peace with PHP
>> being (mostly) case-insensitive.
> We can't make it optional.
On 8/13/05 2:25 AM, "Ilia Alshanetsky" <[EMAIL PROTECTED]> wrote:
> Why would I need name spaces for basic functions, just so that I need to
> rename all my code to use str:replace rather then str_replace and
> perform 2 hash table lookups?
>
Or maybe so that you don't have to look at the manual
On Sat, 13 Aug 2005, Ilia Alshanetsky wrote:
> I thought we've discussed making one access code-units and the other
> code-points?
And the reason why I want this is speed. [1231231] vs. {1231231}, having
the first one access codeunits would be quite a lot faster as not the
whole string has to b
On Fri, 12 Aug 2005, steve roussey wrote:
> > 4. Include an opcode cache by default. A lot of work has gone into
> >pecl/apc recently, but I am not hung up on which one goes in.
>
> I have no karma to +1, but would if I could. It would be wonderful if
> something like xdebug could profile wi
On Fri, 12 Aug 2005, Sara Golemon wrote:
> > 7. Make identifiers case-sensitive
> >
> Or perhaps optionally case sensitive? I dunno, I've made my peace with PHP
> being (mostly) case-insensitive.
We can't make it optional... that would be just too much problems for
writing portable scripts.
De
On Fri, 12 Aug 2005, Ilia Alshanetsky wrote:
> > I have a #9 to share, too:
> > Assuming that PHP 6.0 will also have namespaces support (which would be
> > cool), it might make sense to move all internal functions to use namespaces
> > (if they support functions sitting in there - doesn't seem lik
On Fri, 12 Aug 2005, George Schlossnagle wrote:
> > I wrote up the following spec for this extension:
> > http://files.derickrethans.nl/filter_extension.html
>
> Where's the part about an application swapping back for the raw arrays (as
> opposed to accessing them specifically as _RAW_GET or what
On Sat, 13 Aug 2005, Marcus Boerger wrote:
> Hello Sebastian,
>
> why is this on gravitonic.com ?
>
> anyway. If we'd use the VBA operator for that then we could use the '.'
> for namespaces and wouldn't run into any trouble with namespaces at all.
> Besides someone wanted to have functions
Hello,
Minor:
11. HTTP response splitting attack protection: Replace \r and \n with
space in header();
Information and patches implementing this can be found at
http://cschneid.com/php/
Your patches are problematic when a proxy kills overlong header lines
that were not split up by the cl
Rasmus Lerdorf wrote:
4. Include an opcode cache by default. A lot of work has gone into
pecl/apc recently, but I am not hung up on which one goes in.
Big +1
9. Named parameters. Preferred way would be via array()-less array
collation as we are already using this in our production system
Hi,
HEAD is currently broken because Wez forgot to change the datetime.h file.
Attached is a patch to fix it.
Nuno
Index: datetime.h
===
RCS file: /repository/php-src/ext/standard/datetime.h,v
retrieving revision 1.23
diff -u -r1.23
Hi Davey Shafik!
On 08/12/05 20:56 you wrote:
> As little as it means, +1
Same from here! :)
Cheers!
Toby
--
Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579
a passion for phphttp://www.schlitt.info
Like to say "thank you"?- http://pear.php.ne
> > 10. namespace support (we are telling everyone php is ready for the big
> > soup. In those scenarios you often find big teams and any help allowing
> > things like dedicated responisbilities and preventing communication
> > problems is more then welcome.)
>
> -1 before, -1 still.
Well... if y
What's bad about using [] for strings? I think people who come from a
C-background (like myself) really like that syntax. I'd prefer it to stay
the way it is.
Ron
"Andrei Zmievski" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> We did, but we never arrived at consensus. I don't rea
Hi
1. Remove register_globals completely
2. Remove magic_quotes_*
3. Add input filter extension which will include a mechanism for
application developers to very easily turn it off which would swap
the raw GPC arrays back in case the site had it turned on by default.
4. Include an opcod
96 matches
Mail list logo
