Everything

php

SOAP's ctor's

php.internals

Marcus Börger

21 years ago

Hello Dmitry,

does anything speak against changing soap's ctor's to
__construct which is the PHP 5 way of doing things? Patch
is attached.

--
Best regards,
Marcus

Ron Korving

21 years ago

Didn't Dmitry fix this a long time ago? My SOAP constructors work fine with
__construct()

Ron

"Marcus Boerger" <helly@php.net> schreef in bericht
news:1774206462.20040909122200@marcus-boerger.de...

Dmitry Stogov

21 years ago

Hi Marcus,

Can you explain for what reason you changed prototype of the
SoapClient::__call?
This broke receiving of SOAP headers.

Dmitry.

Marcus Börger

21 years ago

Hello Dmitry,

Thursday, September 9, 2004, 5:59:11 PM, you wrote:

> Hi Marcus,

> Can you explain for what reason you changed prototype of the
> SoapClient::__call?
> This broke receiving of SOAP headers.

__call() is an engine feature that requires either three (PHP 4)
or exactly 2 (PHP 5) parameters. If you need a more complex
function then you need to provide a separate function and
probably map both the new and _call onto a combined implementation.

best regards
marcus

Dmitry Stogov

21 years ago

Hi Marcus,

May be it make sence, but I am not sure with you.

At first, if you think __call()/__get()/__set() mast conform to uniform
prototypes and extension will define methods with another prototypes then
PHP should not work with such extensions.
Warning is very bed decision for binary extensions.
What will poor PHP programmer think about this warning?

Really, it is not a problem for me to add a new function to ext/soap, that
will make complicated call with SOAP headers and so on.
But changing extension API can be a problem for its users.

Thanks. Dmitry.

Marcus Börger

21 years ago

Hello Dmitry,

Thursday, September 9, 2004, 7:39:03 PM, you wrote:

> Hi Marcus,

> May be it make sence, but I am not sure with you.

> At first, if you think __call()/__get()/__set() mast conform to uniform
> prototypes and extension will define methods with another prototypes then
> PHP should not work with such extensions.
> Warning is very bed decision for binary extensions.
> What will poor PHP programmer think about this warning?

> Really, it is not a problem for me to add a new function to ext/soap, that
> will make complicated call with SOAP headers and so on.
> But changing extension API can be a problem for its users.

> Thanks. Dmitry.

Na, i have to thank that you did the work and renamed that function.
The point is that we need to prevent ourselvs from misusing some
facilities because we would write bad/inconsistent or even faulting
code.

best regards
marcus

Dmitry Stogov

21 years ago

Hi Marcus,

May be your patch make sense.
But what is the difference between SoapServer::SaopServer and
SoapServer::__construct?
For me, they are equivalent.

Thanks. Dmitry.

Marcus Börger

21 years ago

Hello Dmitry,

Thursday, September 9, 2004, 6:26:42 PM, you wrote:

> Hi Marcus,

> May be your patch make sense.
> But what is the difference between SoapServer::SaopServer and
> SoapServer::__construct?
> For me, they are equivalent.

__construct is the PHP 5 way whereas using the class name (PHP 4)
way requires some strange work around in the engine code.

marcus

Dmitry Stogov

21 years ago

Hi Marcus,

I looked into you ctor's patch and found that it breaks some tests (For
example: ext/soap/tests/transport001.phpt)
I didn't understand what is wrong. :(
I will not apply it now.

I made alias for __call() with another prototype, so now I have not problems
with SOAP headers receiving.

Thanks. Dmitry.

Marcus Börger

21 years ago

Hello Dmitry,

Friday, September 10, 2004, 11:07:12 AM, you wrote:

> Hi Marcus,

> I looked into you ctor's patch and found that it breaks some tests (For
> example: ext/soap/tests/transport001.phpt)
> I didn't understand what is wrong. :(
> I will not apply it now.

Well then let's hope MySQLi and SOAP stay the only two extensions that
use PHP 4 naming even though they are PHP 5.

best regards
marcus