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
> 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 (mo
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 furthe
> 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.
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. warn
> > -) 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?
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 -
> 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 ha
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 e
> -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 so
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 h
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, s
> 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 thi
13 matches
Mail list logo
