Sebastian Bergmann wrote:
netcat wrote:
Named parameters - i think is very good idea.
Named parameters are commonly implemented using an associated array in
PHP:
which is a nightmare performancewise and suboptimal as far as
syntax is concerned as the additional 'array(' keyword needed
serves
This does appear to fix it.. (diff attached) - however I'm not sure if
there are any knock on effects that this may cause?
Regards
alan
[EMAIL PROTECTED] wrote:
This may be where the problem:
zend_get_parameters_array_ex(ZEND_NUM_ARGS(), args);
Would this do the trick?
zend_get_parameter
Hartmut Holzgraefe wrote:
Sebastian Bergmann wrote:
netcat wrote:
Named parameters - i think is very good idea.
Named parameters are commonly implemented using an associated array in
PHP:
which is a nightmare performancewise and suboptimal as far as
syntax is concerned as the additional 'a
Sebastian Bergmann wrote:
Named parameters are commonly implemented using an associated array in
PHP:
foo(
array(
'foo' => 'bar',
'bar' => 'foo'
)
);
?>
So, how do you think that isn't known to the original poster as he even
explicitely states that
Hi,
I agree with Dan´s opinion.
Watching from a point of view of a developer working
on PHP Object Oriented aplications, libs, frameworks,
etc, there is no sense on things like this. Or it IS
object oriented or it IS NOT. Partiality always run
into complications. And that was what happen on P
I've written a PHP sapi to use PHP as component from within OpenGroupware Webserver
and access and a PHP module to access its internals. I'm going to release it under
BSD-like license. I'm interested in incorporating it in official PHP distribution.
--
PHP Internals - PHP Runtime Development Ma
At 07:17 AM 10/24/2003 -0700, Eduardo R. Maciel wrote:
Hi,
I agree with Dan´s opinion.
Watching from a point of view of a developer working
on PHP Object Oriented aplications, libs, frameworks,
etc, there is no sense on things like this. Or it IS
object oriented or it IS NOT. Partiality alway
Hey,
I've rolled RC1 of beta 2. Although it's a beta I thought it'd be a good
idea to roll an RC so that we can at least do a sanity check to see that
the package is OK and builds.
http://www.php.net/~andi/php-5.0.0b2RC1.tar.bz2
http://www.php.net/~andi/php-5.0.0b2RC1.tar.gz
Please let me know
On Friday, October 24, 2003, at 10:06 AM, Andi Gutmans wrote:
Hey,
I've rolled RC1 of beta 2. Although it's a beta I thought it'd be a
good idea to roll an RC so that we can at least do a sanity check to
see that the package is OK and builds.
http://www.php.net/~andi/php-5.0.0b2RC1.tar.bz2
ht
On Friday, October 24, 2003, at 10:06 AM, Andi Gutmans wrote:
Hey,
I've rolled RC1 of beta 2. Although it's a beta I thought it'd be a
good idea to roll an RC so that we can at least do a sanity check to
see that the package is OK and builds.
http://www.php.net/~andi/php-5.0.0b2RC1.tar.bz2
ht
> Locale settings affecting float parsing [tests/lang/034.phpt]
This fails on all MacOS installs (even with prior PHP) due to locale handling
bug. MacOS claims switch locale, but does not actually do it.
> Bug #25547 (error_handler and array index with function call)
> [tests/lang/bug25547.phpt]
On Sat, 25 Oct 2003, George Schlossnagle wrote:
> How do you make this work without libxml2 (Sterling??)? That's an
> utter pain to get built on os x.
FWIW, I've had good success using fink to install libxml2 and libxsl;
however, in order to get a version of libxml2 high enough (2.5.10) to
wor
On Friday, October 24, 2003, at 11:49 AM, Adam Maccabee Trachtenberg
wrote:
On Sat, 25 Oct 2003, George Schlossnagle wrote:
How do you make this work without libxml2 (Sterling??)? That's an
utter pain to get built on os x.
FWIW, I've had good success using fink to install libxml2 and libxsl;
At 11:53 AM 10/25/2003 -0700, George Schlossnagle wrote:
On Friday, October 24, 2003, at 11:49 AM, Adam Maccabee Trachtenberg wrote:
On Sat, 25 Oct 2003, George Schlossnagle wrote:
How do you make this work without libxml2 (Sterling??)? That's an
utter pain to get built on os x.
FWIW, I've ha
On Fri, 24 Oct 2003, Adam Maccabee Trachtenberg wrote:
> FWIW, I've had good success using fink to install libxml2 and libxsl;
> however, in order to get a version of libxml2 high enough (2.5.10) to
> work with PHP, you need to build from the "unstable" tree.
Great, just what I want, yet another
External dependencies are frustrating, but you could always disable
compilation of all the xml extensions (I do that all the time). That said, do
we really need just about every XML extension enabled by default and if we
do, perhaps a 'global' --disable-all-xml flag should be in order?
Ilia
--
Hi internals !
I came into a problem when writing an IDL to PHP5 language mapping
specification and an IDL to PHP5 language compiler. I'm using the community
OpenORB IDL-to-Java compiler as a base for writing the IDL-to-PHP5 compiler,
in fact, it is a translation from Java to PHP5. Everything is o
> IMHO, I think that replicating the finally code at the end of every catch
> block, before every throw/return statement and at the end of the try/catch
> statement justify the need of "finally".
My mistake, it's not necessary to replicate the code at the end of every
catch block.
And I forgot to m
On Fri, 24 Oct 2003, Ilia Alshanetsky wrote:
> External dependencies are frustrating, but you could always disable
> compilation of all the xml extensions (I do that all the time). That said, do
> we really need just about every XML extension enabled by default and if we
> do, perhaps a 'global
Sorry,
I just find it annoying that something that has worked out of the box
before (compiling PHP with default settings) is now no longer able to do
so easily (on my particular platform).
On Fri, 24 Oct 2003, Ilia Alshanetsky wrote:
> External dependencies are frustrating, but you could always
One solution which was to bundle libxml with PHP got rejected and if my
recollection is correct you agreed with that decision. IMHO that was a good
decision, bundling a huge library (3.2+ megs as of 2.6.0) almost as big as
PHP itself seems kind of strange.
Reverting back to expat does not app
On October 24, 2003 04:27 pm, Adam Maccabee Trachtenberg wrote:
> That sounds like a great idea. Also, George was saying that he was
> unable to disable all the xml extensions, at least on Mac OS X.
I used --disable-all followed by a list of extensions I want to enable. This
seems to work with la
Michael Walter wrote:
(the common) way of faking named parameters, you rely on a) hash lookups
at execution time (for _every_ call) and b) on manually dealing with
default values.
I'd even be happy to accept these two drawbacks but the ugliness of the
array() solution is what I'd like to get rid
At 03:50 PM 10/24/2003 -0400, Dan Kalowsky wrote:
On Fri, 24 Oct 2003, Adam Maccabee Trachtenberg wrote:
> FWIW, I've had good success using fink to install libxml2 and libxsl;
> however, in order to get a version of libxml2 high enough (2.5.10) to
> work with PHP, you need to build from the "unst
We have had discussions about named parameters in the past.
They won't be supported for PHP 5. In any case, even if they are supported
by the engine they will still be very inefficient and will just bloat PHP.
Most languages do without them and I think PHP can do so too.
Andi
At 11:13 PM 10/24/2
Andi Gutmans wrote:
[snip]
This issue is definitely not a reason to stop rolling out RC's nor betas.
Enabling the XML extensions by default is the right decision because
this is an important technology which almost every PHP user will need.
I do think it's a good idea though to have a --disable
On Sat, 25 Oct 2003, George Schlossnagle wrote:
>That wasn't quite my point, I should have been more clear. I have
>libxml2 on my box. It was a pain to build. Supposedly, it is possible
>to disable the need for xml on the system, however if I uninstall
>libxml2 and run
>
>./configure --disab
> > This issue is definitely not a reason to stop rolling out RC's nor
betas.
> > Enabling the XML extensions by default is the right decision because
> > this is an important technology which almost every PHP user will
need.
> > I do think it's a good idea though to have a --disable switch that
>
When configuring PHP 5 for Mac OS X, I get this every time, even with
2.5.10 installed:
not found
configure: error: Please reinstall the libxml >= 2.4.14 distribution
What is the deal?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ilia Alshanetsky wrote:
One solution which was to bundle libxml with PHP got rejected and if my
recollection is correct you agreed with that decision. IMHO that was a good
decision, bundling a huge library (3.2+ megs as of 2.6.0) almost as big as
PHP itself seems kind of strange.
Reverting
Can someone have a look at this - it appears to work now. - eg. It runs
overloaded classes ok without segfaulting.
Regards
Alan
--
Edit this bug report at http://bugs.php.net/?id=25831&edit=1
[EMAIL PROTECTED] wrote:
ID: 25831
Updated by: [EMAIL PROTECTED]
Reported By: v
31 matches
Mail list logo
