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 or later your
objects create text simplifying that aas
On Aug 12, 2005, at 11:29 PM, Ilia Alshanetsky wrote:
12. {} vs [] cleanup
unicode support already makes such distinction it.
No, it doesn't. That's one of the thorny unresolved issues.
-Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
I thought we've discussed making one access code-units and the other
code-points?
Ilia
Andrei Zmievski wrote:
On Aug 12, 2005, at 11:29 PM, Ilia Alshanetsky wrote:
12. {} vs [] cleanup
unicode support already makes such distinction it.
No, it doesn't. That's one of the thorny
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, with some sort of BC switch.
-Andrei
On Aug 12, 2005, at
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
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 really
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 you're so
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?-
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
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
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
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 in
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 whatever)?
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.
Derick
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 with op
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 be
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
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... that
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
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
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 arrays
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 sitting
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.
We can't
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 peace with PHP
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
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
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 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
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 lookups?
+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]
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
* 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.
--
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 matter
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
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 be via
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 -
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
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 actually
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) we
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.
But
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:03:59 2005
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
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
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
surrogates ?
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) =
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] [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.c
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]
And
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
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
Ron Korving wrote:
16. Support for ?php=foo ?
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
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
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
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
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 one
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 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 this
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: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.
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
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 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.
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
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
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
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
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
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
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, 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
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
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 that
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.. i
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, please
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
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
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 ?php
Agreed (though not so much nuke as default to off).
Whenever open tags comes up, I'll toss script language=php into the
conversation and get
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
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 ?php
Agreed (though not so much nuke as default to off).
Whenever open tags comes up, I'll toss script
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:
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);
}
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
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
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:
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;
}
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 function or
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
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 UCS2
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
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
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;
t_len =
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.
-Andrei
92 matches
Mail list logo
