Add PEAR package Validate_FI to CVS. I'm the lead developer. I need access to
the package and documentation.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Andrei, et al.,
I was just looking at README.UNICODE, regarding interpretation of
numbers:
we restrict numbers to consist only of ASCII digits, and Numeric
strings
are supposed to adhere to the same rules. Is it correct to take
that to
mean only UChar's with values from
Hello all.
I would like to propose a replacement for current zend_u_strtod()
implementation.
The patch: http://tony2001.phpclub.net/dev/tmp/u_strtod.diff
According to my tests, new implementation is faster in about 40 (forty) times.
The simple script below takes ~1 sec to run with the patch
Zitat von Dmitry Shirokov [EMAIL PROTECTED]:
Hey guys.
What are you thinking about adding this feature:
?php
function foo()
{
return array(1,2,3,4,5,6);
}
echo foo()[4]; // it that
// or may be (foo())[4] ?
// instead of
$var = foo();
echo $var[4];
?
Yes, please, that would be
Hi Antony,
- Original Message -
From: Antony Dovgal
Sent: Friday, November 10, 2006
Hello all.
I would like to propose a replacement for current zend_u_strtod()
implementation.
The patch: http://tony2001.phpclub.net/dev/tmp/u_strtod.diff
According to my tests, new implementation is
Stanislav Malyshev wrote:
I'd say expression(f()[1]) means $tmp = f(); expression($tmp);
unset($tmp); which here means:
$tmp = foo();
$tmp[1] = 4;
unset($tmp);
which is meaningless but should work. IIRC the engine can make free's at
the end of expression, so it shouldn't be big problem.
On 11/10/2006 02:14 PM, Matt Wilmas wrote:
Hi Antony,
- Original Message -
From: Antony Dovgal
Sent: Friday, November 10, 2006
Hello all.
I would like to propose a replacement for current zend_u_strtod()
implementation.
The patch: http://tony2001.phpclub.net/dev/tmp/u_strtod.diff
On Fri, Nov 10, 2006 at 12:55:45PM +0100, Sebastian Bergmann wrote:
Dmitry Shirokov wrote:
?php
function foo()
{
return array(1,2,3,4,5,6);
}
echo foo()[4]; // it that
// or may be (foo())[4] ?
// instead of
$var = foo();
echo $var[4];
?
Although I am
Hi,
I see this is the time to do language feature request. So let me add
another. I very often use something like:
/$a = isset($x['abc']) ? //$x['abc'] : null;
/This is to prevent an E_NOTICE from being thrown.
This subject is already discussed many times, which led to a suggestion
for PHP6
read the archives, there's been a LOT of discussion about this already.
AFAIK the team decided not to implement this before PHP 6.0.
- tul
Arnold Daniels wrote:
Hi,
I see this is the time to do language feature request. So let me add
another. I very often use something like:
/$a =
Did it not work for you as-is on Windows...? It did for me, since it
seems
there's already a typedef for __int64 - long long. I'd wondered the
same,
I think some VC versions on windows don't know long long but do know
__int64, but I don't remember from the top of my head which version,
Hi Andrei,
All right, glad I checked. I had a few things in mind to optimize
is_numeric_string/unicode, and it's fairly straightforward in _string, but
would just make things slower if u_* functions were needed to do the same in
_unicode, so I was going to rethink it. Now whatever I come up
Hi Derick,
Would this patch provide any benefits for people outside EZ corporation?
You seem to think that It wouldn't since you din't bother to ask the
rest of the PHP devs on internals. Could you please explain?
Edin
Derick Rethans wrote:
derickFri Nov 10 12:02:51 2006 UTC
Arnold Daniels wrote:
I see this is the time to do language feature request. So let me add
another. I very often use something like:
/$a = isset($x['abc']) ? //$x['abc'] : null;
/This is to prevent an E_NOTICE from being thrown.
It seems to me like adding a function:
mixed array_get(mixed
On 11/10/2006 12:21 AM, Dmitry Shirokov wrote:
Hey guys.
What are you thinking about adding this feature:
?php
function foo()
{
return array(1,2,3,4,5,6);
}
echo foo()[4]; // it that
// or may be (foo())[4] ?
// instead of
$var = foo();
echo $var[4];
?
I would really like to
Hello all,
A number of factors have come together to prompt me to possibly commit
mailing-list-suicide by re-opening the namespace issue.
Last week at Zendcon, a number of PHP developers/community members
chatted about namespaces in PHP 6. That chat was the prime motivator for
this email, but
On 10-Nov-06, at 11:51 AM, Sean Coates wrote:
The way I see it is that implementing namespaces is a technical
hurdle,
and the reasons we haven't jumped it are political, not technical.
That's a bit of a circular logic no? There are indeed technical
challenges to implementing namespaces,
That's a bit of a circular logic no? There are indeed technical
challenges to implementing namespaces, these reasons have been covered
in previous discussions many times, since no adequate solution was
devised they were never implemented. Once those issues are resolved or
at the very least
Too long of an email to read :) but just wanted to give a heads-up that we
haven't forgotten about this (it's on the PHP 6 list).
We'll try and come with a proposal in the coming weeks with a way to do it.
-Original Message-
From: Sean Coates [mailto:[EMAIL PROTECTED]
Sent: Friday,
Ilia Alshanetsky wrote:
If anything it'll make code complex and intertwined, introduce serious
scope issue most people have not had to consider up until now and so
on. It will without a doubt increase language complexity as well, which
generally translates to a loss in performance.
Am I
On 10-Nov-06, at 12:41 PM, Sean Coates wrote:
I don't think namespaces are a magic bullet. As it stands, it's
impossible to use namespaces without a third party patch that may
or may
not work. I strongly believe that if namespaces are implemented in PHP
6, most of our prefixing/symbol
Derick Rethans wrote:
derick Fri Nov 10 12:02:51 2006 UTC
Modified files: (Branch: PHP_5_2)
/ZendEngine2 zend_language_scanner.l
Log:
- Forward port the binary cast, which will do the same as the string cast in
PHP 5.2.
What this is supposed to do in
On 10-Nov-06, at 12:54 PM, Sebastian Bergmann wrote:
Ilia Alshanetsky wrote:
If anything it'll make code complex and intertwined, introduce
serious
scope issue most people have not had to consider up until now and so
on. It will without a doubt increase language complexity as well,
which
PHP 6 is not yet out and probably won't be production quality for quite
some time. Which means that migration to it en mass is probably not
going to happen this decade :-).
snippitysnip/
I'm not talking about forcing everyone to use namespaces tomorrow. I'm
trying to plan for a future where
Ilia Alshanetsky wrote:
As your key size increases the slower the key hash generation process
becomes, if you look at the PHP's hash key generation code you'll see
that it works best for 8 or less chars, anything longer and the
performance starts to drop.
It's been a long time since I
On 10 Nov 13:05, Ilia Alshanetsky wrote:
On 10-Nov-06, at 12:41 PM, Sean Coates wrote:
[...]
I also don't deny that there will be a minor performance hit. There are a
ton of other things in PHP that reduce performance.. the idea is to find
a balance of which ones are worth it (as we did
On 10-Nov-06, at 1:19 PM, Sean Coates wrote:
PHP 6 is not yet out and probably won't be production quality for
quite
some time. Which means that migration to it en mass is probably not
going to happen this decade :-).
snippitysnip/
I'm not talking about forcing everyone to use namespaces
I think there is far more
demand for a fast stable PHP then for syntatic sugar features which
seem extremely useful, but in the end prove to carry too much baggage.
Nothing has been proven either way.. at least not publicly.. unless I
just missed it.
I haven't talked to a single
Unfortunately namespaces are not only syntactic sugar, but dire necessity
for PHP if it wants to be taken as a serious langauage and defend it's
position against other arising 'web scripting' alternatives.
It seems the list of things that PHP needs to be taken as a serious
langauage is never
Brian Moon wrote:
Unfortunately namespaces are not only syntactic sugar, but dire
necessity
for PHP if it wants to be taken as a serious langauage and defend it's
position against other arising 'web scripting' alternatives.
It seems the list of things that PHP needs to be taken as a serious
Hi,
I've got another newbie question. My .ini parser now works correctly
when parsing a string (thanks to help of Matt Wilmas). With the same
function I want to be able to parse content of a stream. I looked at
fgets to see how to read a line from a stream. Unfortunately when I call
Hi,
errors complaining about something related to tsrm_ls mean that you're
building a thread-safe PHP and forgot some TSRMLS[_...] macros.
See for example
http://blog.libssh2.org/index.php?/archives/22-What-the-heck-is-TSRMLS_CC-anyway.html
for more about these macros. This should help you, but
Daniel T. Gorski wrote:
Escpecially due to the new OO features of PHP 5, namespaces are urgently
required for writers of independent libraries which should not clash.
I would claim exactly the opposite.
That's because you already get scoping on names, for free, when you use
objects. The
While I could munge the class names in one or more packages as you
suggest then I'm in maintainability hell because when I need to update
one of the other packages (for security, features or bugfixes) you have
to do the name munging again.
C'mon, that ain't right. Next excuse?
--Tony
Patrick Mueller wrote:
There would typically be a one time 'hit' in your code for a long,
prefixed named used as a constructor, or possibly a static method called
on a factory. After that, if you're dealing with object instances, then
instead of function names (which would need to also use
On 10-Nov-06, at 4:57 PM, Tony Bibbs wrote:
While I could munge the class names in one or more packages as you
suggest then I'm in maintainability hell because when I need to
update one of the other packages (for security, features or
bugfixes) you have to do the name munging again.
On 10-Nov-06, at 5:01 PM, Lukas Kahwe Smith wrote:
Remember the point Sebastian made earlier. Its also a hassle during
development of the library code itself, where you have to deal with
endlessly long class names.
You still have the same long names, you've just split them into two
Ilia Alshanetsky wrote:
If you properly pick a
classname you almost never need to rename it let alone the methods
contained with the class. Plus namespaces are going to introduce their
own sets of problems where extension X adds namespace X, which some lib
already decided to use and we are
Tony Bibbs wrote:
While I could munge the class names in one or more packages as you
suggest then I'm in maintainability hell because when I need to update
one of the other packages (for security, features or bugfixes) you have
to do the name munging again.
C'mon, that ain't right. Next
Hello Dmitry,
the major problem here is that people have a wrong understanding of what
it would do. Without return by reference it creates copies which not only
makes assignments useless but also read code very slow. To overcome this,
we would need to discuss another error message's
Hello Edin,
is it so hard to understand? Ok just kidding, it might not be obvious but
as soon as you start to develop stuff that is supposed to run onboth 5 and 6
binary makesa bunch of things easier. Somehow like having var in 5 - only
the other way round.
best regards
marcus
Friday,
Marcus Boerger wrote:
Hello Edin,
is it so hard to understand? Ok just kidding, it might not be obvious but
as soon as you start to develop stuff that is supposed to run onboth 5 and 6
binary makesa bunch of things easier. Somehow like having var in 5 - only
the other way round.
There are
On 10-Nov-06, at 6:24 PM, Stanislav Malyshev wrote:
Marcus Boerger wrote:
Hello Edin,
is it so hard to understand? Ok just kidding, it might not be
obvious but
as soon as you start to develop stuff that is supposed to run
onboth 5 and 6
binary makesa bunch of things easier. Somehow like
Hello Hans,
Friday, November 10, 2006, 8:30:55 PM, you wrote:
Brian Moon wrote:
Unfortunately namespaces are not only syntactic sugar, but dire
necessity
for PHP if it wants to be taken as a serious langauage and defend it's
position against other arising 'web scripting' alternatives.
It
Please, lets keep 5.x code in 5.x and 6.x code in 6.x, different
branches exist for a good reason.
Well, then I guess we shouldn't have (binary) in 5.x?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP Internals - PHP Runtime Development Mailing
Hi again,
I thought that this might not be interesting enough for the list. But
I'll be sure CC it in the future.
Thanks for your help, the extension now builds. It doesn't run however.
I crashes on PHP_STREAM_TO_ZVAL(stream, in). But I'm sure I'm able to
fix that problem myself.
Thanks
Stanislav Malyshev wrote:
Please, lets keep 5.x code in 5.x and 6.x code in 6.x, different
branches exist for a good reason.
Well, then I guess we shouldn't have (binary) in 5.x?
A lot of functions in PHP 6 are able to take both binary and Unicode
strings and act differently when they are
Hello,
On 11/10/06, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello Edin,
is it so hard to understand? Ok just kidding, it might not be obvious but
as soon as you start to develop stuff that is supposed to run onboth 5 and 6
binary makesa bunch of things easier. Somehow like having var in 5 -
Hi,
I've noticed that building an extension will fail when using macro
php_stream_from_zval and there is not return_value variable within the
scope.
/root/php-5.1.6/ext/hello/hello.c: In function `streamit':
/root/php-5.1.6/ext/hello/hello.c:58: error: `return_value' undeclared
(first use
On 11/11/2006 04:13 AM, Arnold Daniels wrote:
Hi,
I've noticed that building an extension will fail when using macro
php_stream_from_zval and there is not return_value variable within the
scope.
Well, looks like it's time to install cscope or ctags and use it to see which
code actually
On Sat, 2006-11-11 at 00:31 +0100, Marcus Boerger wrote:
Hello Hans,
Friday, November 10, 2006, 8:30:55 PM, you wrote:
Brian Moon wrote:
Unfortunately namespaces are not only syntactic sugar, but dire
necessity
for PHP if it wants to be taken as a serious langauage and defend it's
Hello Internals.
I'm not sure how many of you know about Phalanger [1][2]. For those who
don't, it's a fairly complete PHP language compiler, compiling PHP5 sources
into MSIL bytecodes, which can then be executed on the .NET platform or
Mono. Since the .NET framework makes heavy use of
Hello,
I haven't had time to work on my patch, but thinking about this some
more, I'm convinced namespaces should only contain classes. The only
problem that was present when permitting functions/constants to be
inside namespaces was the ambiguity in ternary expressions. By just
supporting
Publish PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
54 matches
Mail list logo
