Re: [PHP-DEV] Re: named function arguments
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 no real purpose here ...
--
Hartmut Holzgraefe <[EMAIL PROTECTED]>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] overload extension
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_parameters_array(ZEND_NUM_ARGS(), args);
On Wednesday, Oct 22, 2003, at 20:47 America/New_York, Alan Knowles wrote:
There is already a bug report on it, however It sounds like it's
unlikely to be fixed in PHP4...
Regards
Alan
[EMAIL PROTECTED] wrote:
The methods of an object that has been passed to the overload()
function lose their ability to have parameters passed by reference.
For example:
class Foo
{
function hello(&$array)
{
$array[] = "hello";
}
}
$array = null;
$foo = & new foo();
$foo->hello($array);
print_r($array)
Output:
Array
(
[0] => hello
)
class Foo extends PEAR_Autoloader
{
function hello(&$array)
{
$array[] = "hello";
}
}
$array = null;
$foo = & new foo();
$foo->hello($array);
print_r($array)
Output:
Nothing!
--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com
? diff.txt
Index: overload.c
===
RCS file: /repository/php-src/ext/overload/Attic/overload.c,v
retrieving revision 1.20.2.3
diff -u -r1.20.2.3 overload.c
--- overload.c 15 Apr 2003 04:14:21 - 1.20.2.3
+++ overload.c 24 Oct 2003 07:50:15 -
@@ -526,7 +526,7 @@
args = (zval ***)emalloc(ZEND_NUM_ARGS() * sizeof(zval **));
- if (zend_get_parameters_array_ex(ZEND_NUM_ARGS(), args) == FAILURE) {
+ if (zend_get_parameters_array(ht, ZEND_NUM_ARGS(), (zval **)args) == FAILURE) {
efree(args);
php_error(E_WARNING, "unable to obtain arguments");
return;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: named function arguments
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 'array(' keyword needed
serves no real purpose here ...
yep, it always looks like a hack.
--
NetCat
---
VIRUS-Free 10mb Free email + Antivirus + POP3 + more...
Get it at http://www.doal.co.il:81/free/?c=all-virus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: named function arguments
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 he wants to remove the need for array()?
> I was also thinking of proposing named parameters, i.e. basically
> removing the need for array() in foo(array('style' => 'hot', 'size' =>
> 42)); but I guess that'll be even more controversial
Also, notice that there is quite a disctinction between keyword/named
parameters and passing an associated array to the function - in the
former case, several optimizations could be implemented at "compile
time" (what is the correct term for this in the PHP model?); in your
(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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] __autoload & exceptions
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 PHP4,
where OO (although good) was the art of
"workarounds"...
IMHO It should be possible to throw exceptions from
anywhere and the exception should be caught not matter
of the scope it is.
The reason for that is simple:
that way, we would not get forced to work with, or
implement, always TWO set of classes/methodes of
"error handlers"(one for errors and other for
exceptions) on libraries, APIs or even applications.
Or use workarounds to create a set of methodes of
error handling using Output Buffering encapsulated
into OO code to get rid of the Fatal Errors for
example. That should not be necessary. With Exceptions
it would be very easier.
And It should be possible to tell the engine to trhow
exceptions instead of errors. Because if it is not
possible, we ran into the same problem above. (forgive
me if it is being implemented now, I´m travelling
since september and can´t follow deep the dev).
But its only my opinion of course.
thanks,
Eduardo R. Maciel
>
> Hi Andi-
>
> Yes, that explains things and makes perfect sense if
> you are just
> writing your
> own web application. Now, consider the new
> __autoload
> functionality from
> a PEAR
> or other large API/library developer standpoint.
>
> The new __autoload functionality lets us:
> - Keep library usage/installation simple by only
> requiring the user to
> include one
> include file regardless of how many possible
> classes or other files
> may be
> needed. This 'initialization' file will setup a
> special autoloader
> for just that library.
> If the user happens to use their own autoloader,
> then they have to
> simply
> setup something like- if (eregi('^libclass_',
> $className)) {
> somelib::autoload($className); }
> A 1, with an optional 2 step install process,
> regardless of which
> parts of the
> library may be used is a good thing. :)
> - Keeps the performance of the library up because
> it
> now only needs to
> load
> class objects the user actually uses.
>
> The new exception handling also lets a library
> developer easily document
> and let a
> user know that mylib will throw exception x, y and
> z.
>
> With that in mind, it's always good practice when
> writing an API/library
> to throw the
> most informative errors possible. Normally, this
> would
> also include
> errors such as
> "Unable to initialize library 'mylib' because file
> 'foo.inc' could not
> be found. Please check
> install documentation.". A much nicer
> exception/error
> than Fatal Error
> in mylib. This
> would also allow the user to catch the error and
> handle it themself, and
> at their
> sole discretion choosing to continue on with script
> execution.
>
> These are just my thoughts and observations after
> writing a large
> API/library in
> PHP5-
>
> Dan Cox
>
> Andi Gutmans wrote:
>
> > Dan,
> >
> > __autoload() is the last chance to load a class
> which is needed before
> > erroring out and terminating the script. By
> design,
> if you don't take
> > advantage of this last chance the script will
> error
> out. Therefore,
> > throwing an exception inside the __autoload()
> function should not be
> > catchable by your script.
> >
> > I hope that explains things.
> >
> > Andi
> >
>
> --
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: jwk
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 Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] __autoload & exceptions
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 always run into complications. And that was what happen on PHP4, where OO (although good) was the art of "workarounds"... There is no such thing as object oriented or not. All OO languages differ. In Java for example, you have to include (import) any class you want to use (unless you are using reflection). __autoload() gives you a shortcut which relieves you from having to include each and every class definition you want to use. But this comes with rules, and the rule is, that if you fail to create the class definition in __autoload() it's a fatal error. I really don't want to discuss this anymore because it's been discussed in the past, and reasons have been given. I've written some sample code lately with __autoload() and I must say it's a dream not having to include all these classes :) Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5 Beta 2 RC1
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 both if it works for you and if it fails. Most changes in the engine are documented in the ZEND_CHANGES file. I'll try and make sure it's updated even further for the real beta 2 release this coming week. Thanks, Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Beta 2 RC1
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 http://www.php.net/~andi/php-5.0.0b2RC1.tar.gz Please let me know both if it works for you and if it fails. Most changes in the engine are documented in the ZEND_CHANGES file. I'll try and make sure it's updated even further for the real beta 2 release this coming week. How do you make this work without libxml2 (Sterling??)? That's an utter pain to get built on os x. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Beta 2 RC1
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 http://www.php.net/~andi/php-5.0.0b2RC1.tar.gz Please let me know both if it works for you and if it fails. Most changes in the engine are documented in the ZEND_CHANGES file. I'll try and make sure it's updated even further for the real beta 2 release this coming week. Only a handful of make test failures on OS X (w/libxml2): = FAILED TEST SUMMARY - Locale settings affecting float parsing [tests/lang/034.phpt] Bug #25547 (error_handler and array index with function call) [tests/lang/bug25547.phpt] serializing references test case using globals [ext/session/tests/019.phpt] Bug #25756 (validate_schema_file() broken) [ext/simplexml/tests/bug25756.phpt] File type functions [ext/standard/tests/file/001.phpt] Check for mktime with out-of-range parameters [ext/standard/tests/time/003.phpt] mktime() [ext/standard/tests/time/mktime.phpt] XML parser test, function callbacks [ext/xml/tests/xml001.phpt] XML parser test, object tuple callbacks [ext/xml/tests/xml002.phpt] XML parser test, xml_set_object callbacks [ext/xml/tests/xml003.phpt] = -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Beta 2 RC1
> 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] Currently fails on PHP5, however works fine in PHP4. > Check for mktime with out-of-range parameters > [ext/standard/tests/time/003.phpt] > mktime() [ext/standard/tests/time/mktime.phpt] Also, a MacOSX specific issue that is not PHP5 specific. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Beta 2 RC1
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 with PHP, you need to build from the "unstable" tree. -adam -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Beta 2 RC1
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; 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. 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 --disable-xml --disable-simplexml --disable-libxml , it errors out because it can't find xml2-config. Which seems to go against the spirit of those flags as I understand them. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Beta 2 RC1
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 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. 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 --disable-xml --disable-simplexml --disable-libxml , it errors out because it can't find xml2-config. Which seems to go against the spirit of those flags as I understand them. I also had some problems a couple of months ago building PHP without XML. Can someone who knows configure well see what the problem is? Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Beta 2 RC1
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 dependency. I fought originally not to depend upon Fink for PHP, and don't really see this as a solution. I'd like to ask that before we continue to roll out RC's and further Beta's that this issue gets solved. It's not only frustrating as a developer, it's also frustrating as an end user (to which my INBOX is a nice testament towards). >---< Dan Kalowsky"I thought you died alone, http://www.deadmime.org/~danka long long time ago." [EMAIL PROTECTED]- "The Man Who Sold the World" [EMAIL PROTECTED] David Bowie -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Beta 2 RC1
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] finally again
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 ok except the
"finally" clause wich doesn't exists in Zend Engine 2. I know that many of
you think that "finally" is useless but consider this case, and if anyone
have a simple and elegant solution without implementing "finally" I'll be
glad to listen.
The code would be like this if we had finally:
_request('bind',true);
org__omg__CosNaming__NameHelper::write($_output,$n);
$_output->write_Object($obj);
$_input = $this->_invoke($_output);
return;
} catch(org__omg__CORBA__portable__RemarshalException $_exception) {
continue;
} catch(org__omg__CORBA__portable__ApplicationException $_exception) {
$_exception_id = $_exception->getId();
if ($_exception_id ==
org__omg__CosNaming__NamingContextPackage__NotFoundHelper::id()) {
throw
org__omg__CosNaming__NamingContextPackage__NotFoundHelper::read($_exception-
>getInputStream());
}
if ($_exception_id ==
org__omg__CosNaming__NamingContextPackage__CannotProceedHelper::id()) {
throw
org__omg__CosNaming__NamingContextPackage__CannotProceedHelper::read($_excep
tion->getInputStream());
}
if ($_exception_id ==
org__omg__CosNaming__NamingContextPackage__InvalidNameHelper::id()) {
throw
org__omg__CosNaming__NamingContextPackage__InvalidNameHelper::read($_excepti
on->getInputStream());
}
if ($_exception_id ==
org__omg__CosNaming__NamingContextPackage__AlreadyBoundHelper::id()) {
throw
org__omg__CosNaming__NamingContextPackage__AlreadyBoundHelper::read($_except
ion->getInputStream());
}
throw new org__omg__CORBA__UNKNOWN("Unexpected User Exception:
$_exception_id");
} catch(Exception $_exception) {
throw $_exception;
} finally {
$this->_releaseReply($_input);
}
...
?>
Since we don't have finally, the current code is:
_request('bind',true);
org__omg__CosNaming__NameHelper::write($_output,$n);
$_output->write_Object($obj);
$_input = $this->_invoke($_output);
$this->_releaseReply($_input); //PHP still does not have FINALLY !!!
return;
} catch(org__omg__CORBA__portable__RemarshalException $_exception) {
$this->_releaseReply($_input); //PHP still does not have FINALLY !!!
continue;
} catch(org__omg__CORBA__portable__ApplicationException $_exception) {
$_exception_id = $_exception->getId();
if ($_exception_id ==
org__omg__CosNaming__NamingContextPackage__NotFoundHelper::id()) {
$this->_releaseReply($_input); //PHP still does not have FINALLY
!!!
throw
org__omg__CosNaming__NamingContextPackage__NotFoundHelper::read($_exception-
>getInputStream());
}
if ($_exception_id ==
org__omg__CosNaming__NamingContextPackage__CannotProceedHelper::id()) {
$this->_releaseReply($_input); //PHP still does not have FINALLY
!!!
throw
org__omg__CosNaming__NamingContextPackage__CannotProceedHelper::read($_excep
tion->getInputStream());
}
if ($_exception_id ==
org__omg__CosNaming__NamingContextPackage__InvalidNameHelper::id()) {
$this->_releaseReply($_input); //PHP still does not have FINALLY
!!!
throw
org__omg__CosNaming__NamingContextPackage__InvalidNameHelper::read($_excepti
on->getInputStream());
}
if ($_exception_id ==
org__omg__CosNaming__NamingContextPackage__AlreadyBoundHelper::id()) {
$this->_releaseReply($_input); //PHP still does not have FINALLY
!!!
throw
org__omg__CosNaming__NamingContextPackage__AlreadyBoundHelper::read($_except
ion->getInputStream());
}
$this->_releaseReply($_input); //PHP still does not have FINALLY !!!
throw new org__omg__CORBA__UNKNOWN("Unexpected User Exception:
$_exception_id");
} catch(Exception $_exception) {
$this->_releaseReply($_input); //PHP still does not have FINALLY !!!
throw $_exception;
}
$this->_releaseReply($_input); //PHP still does not have FINALLY !!!
...
?>
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".
If there is another aproach without "finally" and without code redundancy, I
really need it.
Best Regards,
Cristiano Duarte
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: finally again
> 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 mention that there must be one "catch all" clause(wich is impossible in PHP) with a copy of the finally code and a rethrowing exception statement otherwise an exception that is not caugh will propagate without executing the replicated code of "finally". Cristiano Duarte -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Beta 2 RC1
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' --disable-all-xml flag should be in order? 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. -adam -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Beta 2 RC1
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 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 > >---< Dan Kalowsky"I thought you died alone, http://www.deadmime.org/~danka long long time ago." [EMAIL PROTECTED]- "The Man Who Sold the World" [EMAIL PROTECTED] David Bowie -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Beta 2 RC1
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 appear like a valid option as that prevents a common backend for all of the xml extensions. Although if someone can come up with a good solution, maybe fall back to expat if no operational libxml is found? Given xml's perceived popularity disabling XML is not an option, that and I believe (not 100% sure) it would cause problems for PEAR. IMHO the best solution would be to leave (some) XML extensions enabled by default, however if libxml cannot be found or is unusable silently disable the affected extensions. Or perhaps give a warning indicating xml extensions are disabled at the end of configure. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Beta 2 RC1
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 latest CVS, perphaps this approach will work on Mac OS X as well? Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: internals Digest 24 Oct 2003 20:08:45 -0000 Issue 194
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 of.
Something like either
foo('x' => 'x-value', 'y' => 'y-value);
or
foo($x => 'x-value', $y => 'y-value');
or
foo(x:'x-value', y:'y-value');
or a mix of one of these solutions would be really handy in writing
readable code.
One thing which would make it really powerful for my purpose would be if
I don't have to declare all possible parameters to my function, i.e. a
way for foo() to find out what arguments were passed to it (name and
value). Something like treating the whole parameter list as an array
definition so that (using the first of the above syntax versions)
foo('x' => 'x-value', 'y' => 'y-value', 'z-value');
would basically be the same as
foo(array('x' => 'x-value', 'y' => 'y-value', 'z-value'));
but more readable (and writable).
I think of the parameter list as a kind of an array anyway, that's why I
think both array()-less named parameters and dangling comma at the end
should be allowed.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Beta 2 RC1
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 "unstable" tree. Great, just what I want, yet another external dependency. I fought originally not to depend upon Fink for PHP, and don't really see this as a solution. I'd like to ask that before we continue to roll out RC's and further Beta's that this issue gets solved. It's not only frustrating as a developer, it's also frustrating as an end user (to which my INBOX is a nice testament towards). 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 and disables all of the XML extensions. IMO, we shouldn't have --disable-simplexml and --disable-xml. We should just have the latter and make it disable/enable all the three XML extensions. There is no real reason not to enable them all. The memory consumption is minimal and once one of them is enabled libXML2 is linked. I don't see any good coming out of reverting back to expat. I think one of the most important "features'" in PHP 5 will be the much better XML support and this is really something PHP users are looking for. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: internals Digest 24 Oct 2003 20:08:45 -0000 Issue 194
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/2003 +0200, Christian Schneider wrote:
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 of.
Something like either
foo('x' => 'x-value', 'y' => 'y-value);
or
foo($x => 'x-value', $y => 'y-value');
or
foo(x:'x-value', y:'y-value');
or a mix of one of these solutions would be really handy in writing
readable code.
One thing which would make it really powerful for my purpose would be if I
don't have to declare all possible parameters to my function, i.e. a way
for foo() to find out what arguments were passed to it (name and value).
Something like treating the whole parameter list as an array definition so
that (using the first of the above syntax versions)
foo('x' => 'x-value', 'y' => 'y-value', 'z-value');
would basically be the same as
foo(array('x' => 'x-value', 'y' => 'y-value', 'z-value'));
but more readable (and writable).
I think of the parameter list as a kind of an array anyway, that's why I
think both array()-less named parameters and dangling comma at the end
should be allowed.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Beta 2 RC1
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 switch that works and disables all of the XML extensions. IMO, we shouldn't have --disable-simplexml and --disable-xml. We should just have the latter and make it disable/enable all the three XML extensions. There is no real reason not to enable them all. The memory consumption is minimal and once one of them is enabled libXML2 is linked. I don't see any good coming out of reverting back to expat. I think one of the most important "features'" in PHP 5 will be the much better XML support and this is really something PHP users are looking for. I asked (and so did someone else) if there is support for XSLT scheme handlers in PHP5. Nobody answered. It was possible in PHP4 with Sablotron. Now the Sablotron PHP extension is gone. So IMHO a very essential XML feature is missing in PHP5. -- Adam Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Beta 2 RC1
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 --disable-xml --disable-simplexml --disable-libxml You missed '--disable-dom' here. I'll look into making '--disable-libxml' to work as you would expect it to work..in couple of weeks. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Beta 2 RC1
> > 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 and disables all of the XML extensions. > > IMO, we shouldn't have --disable-simplexml and --disable-xml. We > > should just have the latter and make it disable/enable all the three > > XML extensions. There is no real reason not to enable them all. The > > memory consumption is minimal and once one of them is enabled libXML2 > > is linked. > > I don't see any good coming out of reverting back to expat. I think > > one of the most important "features'" in PHP 5 will be the much better > > XML support and this is really something PHP users are looking for. > > I asked (and so did someone else) if there is support for XSLT scheme > handlers in PHP5. Nobody answered. It was possible in PHP4 with > Sablotron. Now the Sablotron PHP extension is gone. So IMHO a very > essential XML feature is missing in PHP5. Hear, hear.. to both of you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Beta 2 RC1
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
Re: [PHP-DEV] PHP 5 Beta 2 RC1
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 back to expat does not appear like a valid option as that prevents a common backend for all of the xml extensions. Although if someone can come up with a good solution, maybe fall back to expat if no operational libxml is found? Given xml's perceived popularity disabling XML is not an option, that and I believe (not 100% sure) it would cause problems for PEAR. I can verify this. PEAR is structured around the ability to parse a package.xml using expat-style parsing. Without xml, there is no PEAR. Regards, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [Fwd: [PATCH] to fix Re: #25831 [Ver]: overload/__call breaks method Pass by reference]
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: viking at dslnorthwest dot net
Status: Verified
Bug Type: Scripting Engine problem
Operating System: all
PHP Version: 4.3.4RC2-dev
New Comment:
--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com
--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com
? diff.txt
Index: overload.c
===
RCS file: /repository/php-src/ext/overload/Attic/overload.c,v
retrieving revision 1.20.2.3
diff -u -r1.20.2.3 overload.c
--- overload.c 15 Apr 2003 04:14:21 - 1.20.2.3
+++ overload.c 25 Oct 2003 04:08:34 -
@@ -507,7 +507,7 @@
static void overload_call_method(INTERNAL_FUNCTION_PARAMETERS,
zend_property_reference *property_reference)
{
zval ***args;
- zval *retval = NULL;
+
int call_result;
zend_bool use_call_handler = 1;
zval *object = property_reference->object;
@@ -526,13 +526,15 @@
args = (zval ***)emalloc(ZEND_NUM_ARGS() * sizeof(zval **));
- if (zend_get_parameters_array_ex(ZEND_NUM_ARGS(), args) == FAILURE) {
- efree(args);
- php_error(E_WARNING, "unable to obtain arguments");
- return;
- }
if (use_call_handler) {
+ zval *retval = NULL;
+
+ if (zend_get_parameters_array_ex(ZEND_NUM_ARGS(), args) == FAILURE) {
+ efree(args);
+ php_error(E_WARNING, "unable to obtain arguments");
+ return;
+ }
zval **handler_args[3];
zval *arg_array;
zval result, *result_ptr = &result;
@@ -588,23 +590,29 @@
}
zval_ptr_dtor(&retval);
} else {
+ zval retval;
+ if (zend_get_parameters_array(ht, ZEND_NUM_ARGS(), (zval **)args) ==
FAILURE) {
+ efree(args);
+ php_error(E_WARNING, "unable to obtain arguments");
+ return;
+ }
+
ZVAL_STRINGL(&call_handler, Z_STRVAL(method->element),
Z_STRLEN(method->element), 0);
- call_result = call_user_function_ex(NULL,
+ call_result = call_user_function(NULL,
&object,
&call_handler,
-
&retval,
-
ZEND_NUM_ARGS(), args,
-
0, NULL TSRMLS_CC);
+
return_value,
+
ZEND_NUM_ARGS(),(zval **)args TSRMLS_CC);
- if (call_result == FAILURE || !retval) {
+ if (call_result == FAILURE || !&return_value) {
efree(args);
php_error(E_WARNING, "unable to call %s::%s() method",
Z_OBJCE_P(object)->name, Z_STRVAL(method->element));
return;
}
- *return_value = *retval;
+
zval_copy_ctor(return_value);
- zval_ptr_dtor(&retval);
+
}
efree(args);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
