[PHP-DEV] Re: zend_API.c
2003-02-02 Harald Radi [EMAIL PROTECTED] * zend_API.c zend_API.h: extend the parameter parsing API by two functions for parsing method parameters with automatic detection if the function was called as such or as a class method (with a valid this ptr). if called as a function the first parameter has to be the object it is operating on, if called as a method this is used. Would have been nice of you to talk with me about this first, since I maintain that code. -Andrei http://www.gravitonic.com/ * Use the source, Luke. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: zend_API.c
hi andrei, what would you think if we add a zend_parse_method_parameters() function to the parse parameters API ? as you're maintaining that part of the code i thought it would be a good idea to ask you first, before i'm going to commit something. :) to be serious: it is not yet used anywhere, so we can still change it however we want. if you think it doesn't belong there we can even remove it, but i already needed that functionality in 3+ extensions and i guess you even will like it for your gtk stuff. i even have to review the thing as i don't think it that it works as expected right now, but i was in a hurry yesterday and made a skeleton for georgs mysqli extension which needed that functions. i also postet a message to php5-dev first but somehow it doesn't show up there (?). harald. Andrei Zmievski [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED]... 2003-02-02 Harald Radi [EMAIL PROTECTED] * zend_API.c zend_API.h: extend the parameter parsing API by two functions for parsing method parameters with automatic detection if the function was called as such or as a class method (with a valid this ptr). if called as a function the first parameter has to be the object it is operating on, if called as a method this is used. Would have been nice of you to talk with me about this first, since I maintain that code. -Andrei http://www.gravitonic.com/ * Use the source, Luke. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: zend_API.c
On Mon, 03 Feb 2003, Harald Radi wrote: it is not yet used anywhere, so we can still change it however we want. if you think it doesn't belong there we can even remove it, but i already needed that functionality in 3+ extensions and i guess you even will like it for your gtk stuff. i even have to review the thing as i don't think it that it works as expected right now, but i was in a hurry yesterday and made a skeleton for georgs mysqli extension which needed that functions. Continuing from IRC discussion: why do we need extensions that provide both function and object APIs for the same functionality? Are we trying to emulate Perl or something? To me, that is introducing more confusion for the sake of flexibility. I am strongly of the opinion that we should stick to having it one way or the other. -Andrei http://www.gravitonic.com/ Music expresses that which can not be said and on which it is impossible to be silent. -Victor Hugo -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: zend_API.c
-Original Message- From: Andrei Zmievski [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 4:04 PM Continuing from IRC discussion: why do we need extensions that provide both function and object APIs for the same functionality? Are we trying to emulate Perl or something? To me, that is introducing more confusion for the sake of flexibility. I am strongly of the opinion that we should stick to having it one way or the other. because people prefer either the one or the other way to manipulate things. people not familiar with oo will most likely not not stick with the oo api nor will they be happy if they're forced to use it. on the other hand people writing their scripts entirely oo will propably hate it to mix function calls with method invokations all the time. furthermore functions are supposed to issue warnings and methods are supposed to throw exceptions, two entirely different concepts of error handling where neitherone is preferable. so the question is to give rope or not. harald. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: zend_API.c
On Mon, 03 Feb 2003, Harald Radi wrote: because people prefer either the one or the other way to manipulate things. people not familiar with oo will most likely not not stick with the oo api nor will they be happy if they're forced to use it. on the other hand people writing their scripts entirely oo will propably hate it to mix function calls with method invokations all the time. furthermore functions are supposed to issue warnings and methods are supposed to throw exceptions, two entirely different concepts of error handling where neitherone is preferable. so the question is to give rope or not. Ugh, so following your line of reasoning we should rewrite all extensions to provide both function and OO apis? A better approach would be to have extensions provide only function API and then write a PEAR class to expose them as objects. -Andrei http://www.gravitonic.com/ * My wishlist: http://www.amazon.com/exec/obidos/wishlist/2Q2DIPY7BZLSH/ * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: zend_API.c
From: Andrei Zmievski [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 4:18 PM so the question is to give rope or not. Ugh, so following your line of reasoning we should rewrite all extensions to provide both function and OO apis? A better approach would be to have extensions provide only function API and then write a PEAR class to expose them as objects. that would be a big step back again for several reasons: -) if done in c code you have one function serving as function and method, thus you have the same order/amount of arguments for the function _and_ the method. -) if something changes in the code, it automatically changes for the function and the method, if we had a pear class someone would have to maintain that. -) we finally brought down the cost of handling object beeing virtually the same as for handling resources, so why should we try that hard to make the damn thing slow again ? -) the errorhandling issue is not (easily) coverable if we simple wrap the funcitons as pear classes. harald -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: zend_API.c
On Mon, 03 Feb 2003, Harald Radi wrote: that would be a big step back again for several reasons: -) if done in c code you have one function serving as function and method, thus you have the same order/amount of arguments for the function _and_ the method. I don't see this as an issue - the OO API in PEAR would be a simple wrapper for the function. -) if something changes in the code, it automatically changes for the function and the method, if we had a pear class someone would have to maintain that. See above. -) we finally brought down the cost of handling object beeing virtually the same as for handling resources, so why should we try that hard to make the damn thing slow again ? You are proving my point - the cost of handling objects is minimal, so why not do it in userland? -) the errorhandling issue is not (easily) coverable if we simple wrap the funcitons as pear classes. What errorhandling issue? -Andrei http://www.gravitonic.com/ * Quantum Mechanics: The Dreams of Which Stuff is Made. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: zend_API.c
-) we finally brought down the cost of handling object beeing virtually the same as for handling resources, so why should we try that hard to make the damn thing slow again ? You are proving my point - the cost of handling objects is minimal, so why not do it in userland? because then we have userland - ze2 oo - userland - php function instead of userland - php function. maybe that's negligable, i didn't benchmark it. -) the errorhandling issue is not (easily) coverable if we simple wrap the funcitons as pear classes. What errorhandling issue? exception vs. warning. harald -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: zend_API.c
On Mon, 03 Feb 2003, Harald Radi wrote: because then we have userland - ze2 oo - userland - php function instead of userland - php function. maybe that's negligable, i didn't benchmark it. Hmm, care to explain this? It should just be object call - PHP function call. exception vs. warning. The underlying function can still print warning. No exceptions needed. -Andrei http://www.gravitonic.com/ Music expresses that which can not be said and on which it is impossible to be silent. -Victor Hugo -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: zend_API.c
On Mon, 03 Feb 2003, Harald Radi wrote:
because then we have userland - ze2 oo - userland - php
function instead of
userland - php function. maybe that's negligable, i didn't
benchmark it.
Hmm, care to explain this? It should just be object call -
PHP function
call.
if $obj is an overloaded object $obj-method() would directly call the native
implementation of method(), if it is a pear object, $obj-method() will result
in a userspace method invokation that actually calls the native implementation
adding a further level of indirection for each method call. for something like
while($mysqli-fetch_row()) {} this could be an issue (though i don't know how
much of an issue).
exception vs. warning.
The underlying function can still print warning. No exceptions needed.
you're missing the point. if i invoke a method i don't expect it to print a
warning, i expect it to throw an exception (most likely) and imho this is the
prevailing opinion in oo.
harald
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: zend_API.c
On Mon, 03 Feb 2003, Harald Radi wrote:
if $obj is an overloaded object $obj-method() would directly call the native
implementation of method(), if it is a pear object, $obj-method() will result
in a userspace method invokation that actually calls the native implementation
adding a further level of indirection for each method call. for something like
while($mysqli-fetch_row()) {} this could be an issue (though i don't know how
much of an issue).
It's a difference between doing a call_user_function_ex() and invoking
the handler directly.
you're missing the point. if i invoke a method i don't expect it to print a
warning, i expect it to throw an exception (most likely) and imho this is the
prevailing opinion in oo.
No, I'm not missing the point. How is this going to be achieved with
your approach? You have the same function handling both function and OO
API? Is it going to throw exception based on how it's called?
-Andrei http://www.gravitonic.com/
The 3 great virtues of a programmer:
Laziness, Impatience, and Hubris.
--Larry Wall
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: zend_API.c
It's a difference between doing a call_user_function_ex() and invoking the handler directly. i don't get your point. how would such a pear class look like ? you're missing the point. if i invoke a method i don't expect it to print a warning, i expect it to throw an exception (most likely) and imho this is the prevailing opinion in oo. No, I'm not missing the point. How is this going to be achieved with your approach? You have the same function handling both function and OO API? Is it going to throw exception based on how it's called? yup, that was the idea. harald -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: zend_API.c
Hey, I think the discussion you guys are having is much broader than just mysqli. We should probably come up with a general approach which we will use consistently for PHP 5. I suggest we move this discussion to the PHP 5 dev list and try and come up with a good solution. Obviously we will keep the functional support for all extensions like PHP 4. The only question is, if and how we support an OO paradigm. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
