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
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?
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
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
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 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
work
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;
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
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
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'
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
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
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
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
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
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
works
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
20 matches
Mail list logo
