Execution order of PHP

Hi,

In a hobby project I'm relying on the order in which the following piece
of PHP code is executed:

$client->system->multiCall(
$client->methodOne(),
$client->methodTwo()
);

Currently PHP always resolves $client->system (and executes the __get on
$client) before resolving the arguments to the multiCall() method call.

Is this order something that is specified by PHP and so can be relied
upon to stay the same in the future or is it just how it currently works.

If it cannot be relied upon to stay this way, I will have to rewrite the
multiCall method and API...

regards,
Auke van Slooten
Muze

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Execution order of PHP

2010/3/10 Auke van Slooten
>
> Hi,
>
> In a hobby project I'm relying on the order in which the following piece =
of PHP code is executed:
>
> $client->system->multiCall(
> =A0$client->methodOne(),
> =A0$client->methodTwo()
> );
>
> Currently PHP always resolves $client->system (and executes the __get on =
$client) before resolving the arguments to the multiCall() method call.

Hi!

Can't you call the methods $client->methodOne() and
$client->methodTwo() before the call to $client->system->multiCall()?
That way, you could store they values in local variables, and then
pass them to the $client->system->multiCall(), assuring that those
methods are executed before the multiCall(). Something like:

$methodOne =3D $client->methodOne();
$methodTwo =3D $client->methodTwo();
$client->system->multiCall($methodOne, $methodTwo);

Cheers,
Bruno.

>
> Is this order something that is specified by PHP and so can be relied upo=
n to stay the same in the future or is it just how it currently works.
>
> If it cannot be relied upon to stay this way, I will have to rewrite the =
multiCall method and API...
>
> regards,
> Auke van Slooten
> Muze
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Execution order of PHP

From: Auke van Slooten

> In a hobby project I'm relying on the order in which the following
piece=20
> of PHP code is executed:
>=20
> $client->system->multiCall(
> $client->methodOne(),
> $client->methodTwo()
> );
>=20
> Currently PHP always resolves $client->system (and executes the __get
on=20
> $client) before resolving the arguments to the multiCall() method
call.
>=20
> Is this order something that is specified by PHP and so can be relied=20
> upon to stay the same in the future or is it just how it currently
works.
>=20
> If it cannot be relied upon to stay this way, I will have to rewrite
the=20
> multiCall method and API...

Think about it from the parser's point of view. It has to evaluate
$client->system to determine the parameter list for multiCall(). Then it
has to evaluate those parameters before it can stuff their values into
the stack so it can call the function. But, whether it evaluates the
parameter list left-to-right or vice versa is implementation dependent.
I don't believe you can rely on it always being the same unless you
always use the same interpreter.

Bob McConnell

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Execution order of PHP

Bruno Fajardo wrote:
> 2010/3/10 Auke van Slooten
>> Hi,
>>
>> In a hobby project I'm relying on the order in which the following piece of PHP code is executed:
>>
>> $client->system->multiCall(
>> $client->methodOne(),
>> $client->methodTwo()
>> );
>
> Can't you call the methods $client->methodOne() and
> $client->methodTwo() before the call to $client->system->multiCall()?
> That way, you could store they values in local variables, and then
> pass them to the $client->system->multiCall(), assuring that those
> methods are executed before the multiCall(). Something like:
>
> $methodOne = $client->methodOne();
> $methodTwo = $client->methodTwo();
> $client->system->multiCall($methodOne, $methodTwo);

Hi,

This is not what I meant. I should perhaps mention that it's an xml-rpc
client and the method calls are remote method calls. The multiCall
method gathers multiple method calls into a single request.

The trick I'm using now is to set a private property in the
$client->__get() method when the property you're accessing is 'system'.
From then untill you call the method 'multiCall', instead of calling
the methods (in this case methodOne and methodTwo) the client creates a
new object with the call information (method name and arguments) and
returns that. In multiCall all arguments are therefor call information
objects and multicall creates a single request based on that information.

So in your example the client would simply call methodOne and methodTwo
and return the results. Then it would try to do a multiCall with
whatever the previous methods have returned.

regards,
Auke van Slooten
Muze

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Execution order of PHP

--=-rTg3cW8IcOc2h13AMJxX
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2010-03-10 at 15:20 +0100, Sándor Tamás wrote:

>=20
> 2010.03.10. 14:41 keltezéssel, Bob McConnell írta:
> > From: Auke van Slooten
> >
> > =20
> >> In a hobby project I'm relying on the order in which the following
> >> =20
> > piece
> > =20
> >> of PHP code is executed:
> >>
> >> $client->system->multiCall(
> >> $client->methodOne(),
> >> $client->methodTwo()
> >> );
> >>
> >> Currently PHP always resolves $client->system (and executes the __get
> >> =20
> > on
> > =20
> >> $client) before resolving the arguments to the multiCall() method
> >> =20
> > call.
> > =20
> >> Is this order something that is specified by PHP and so can be relied
> >> upon to stay the same in the future or is it just how it currently
> >> =20
> > works.
> > =20
> >> If it cannot be relied upon to stay this way, I will have to rewrite
> >> =20
> > the
> > =20
> >> multiCall method and API...
> >> =20
> > Think about it from the parser's point of view. It has to evaluate
> > $client->system to determine the parameter list for multiCall(). Then i=
t
> > has to evaluate those parameters before it can stuff their values into
> > the stack so it can call the function. But, whether it evaluates the
> > parameter list left-to-right or vice versa is implementation dependent.
> > I don't believe you can rely on it always being the same unless you
> > always use the same interpreter.
> >
> > Bob McConnell
> >
> > =20
> I think it cannot be that the evaluation order of the parameters is=20
> implementation dependent.
> Just think about it:
> $someobject->method($a++, $a++);
>=20
> What will be the result? Or there has to be some directive to tell the=20
> parser to evaluate the parameters from left to right or vice versa.
> And if there isn't, in some future release, there has to be.
>=20
> SanTa
>=20


The order is implementation dependent, and just follows from other
languages which behave exactly the same (I believe Java and C++ both do)

This is the sort of example that's used as a reason to not rely on such
behaviour. You just have to work around it I guess.

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-rTg3cW8IcOc2h13AMJxX--

Re: Execution order of PHP

--------------ms070607060200040907020204
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable



2010.03.10. 14:41 keltez=E9ssel, Bob McConnell =EDrta:
> From: Auke van Slooten
>
> =20
>> In a hobby project I'm relying on the order in which the following
>> =20
> piece
> =20
>> of PHP code is executed:
>>
>> $client->system->multiCall(
>> $client->methodOne(),
>> $client->methodTwo()
>> );
>>
>> Currently PHP always resolves $client->system (and executes the __get
>> =20
> on
> =20
>> $client) before resolving the arguments to the multiCall() method
>> =20
> call.
> =20
>> Is this order something that is specified by PHP and so can be relied
>> upon to stay the same in the future or is it just how it currently
>> =20
> works.
> =20
>> If it cannot be relied upon to stay this way, I will have to rewrite
>> =20
> the
> =20
>> multiCall method and API...
>> =20
> Think about it from the parser's point of view. It has to evaluate
> $client->system to determine the parameter list for multiCall(). Then i=
t
> has to evaluate those parameters before it can stuff their values into
> the stack so it can call the function. But, whether it evaluates the
> parameter list left-to-right or vice versa is implementation dependent.=

> I don't believe you can rely on it always being the same unless you
> always use the same interpreter.
>
> Bob McConnell
>
> =20
I think it cannot be that the evaluation order of the parameters is=20
implementation dependent.
Just think about it:
$someobject->method($a++, $a++);

What will be the result? Or there has to be some directive to tell the=20
parser to evaluate the parameters from left to right or vice versa.
And if there isn't, in some future release, there has to be.

SanTa


--------------ms070607060200040907020204
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIMcDCC
BjQwggUcoAMCAQICEA+FQLvD2rs4hOLLitSNT8AwDQYJKoZIhvcNAQEFBQAw ga4xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkx HjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3Qu
Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQg
RW1haWwwHhcNMTAwMjIzMDAwMDAwWhcNMTEwMjIzMjM1OTU5WjCB3zE1MDMG A1UECxMsQ29t
b2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBE BgNVBAsTPVRl
cm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5jb21vZG8u bmV0L3JlcG9z
aXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0ZWQxFTATBgNV BAMTDFRhbWFz
IFNhbmRvcjEmMCQGCSqGSIb3DQEJARYXc2FuZG9ydGFtYXNAaG9zdHdhcmUu aHUwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3ZTQIMO6gYKmiAChodNkcS1p6 B/Oa/wBV0OFh
MzPjs1e95CKh05RcybOH3dwfRErFzUPwClER0GdjSl+80xCeNF4ysRjdtj4Q MAVNdXakwIV7
DfHEaJI6c+DmY2o2x/ahvvNJueHXmhQXfChDcdkwNHP2AX0C9AZzSorTlf8S mARzAj/YSvIC
s8RSI9iZTkke5XhVcQYwOXLoFLkKYaSGSc37mOM0gD3LDOhB64HfanRnO242 NwgSB8Tfz3DZ
NTCSqzSwfDd2I59G3jLuy1wl9Tjlr0TXGF9KSg8ZveH35xCuTzXdl69NqJ9w lVKQlUHXDohh
TqjtqUkB7LIDqDaPAgMBAAGjggIZMIICFTAfBgNVHSMEGDAWgBSJgmd9xJ0m cABLtFBIfN49
rgRufTAdBgNVHQ4EFgQU1cKL0dFSyu3CT39ib6UFMbVPfykwDgYDVR0PAQH/ BAQDAgWgMAwG
A1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC MBEGCWCGSAGG
+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG AQUFBwIBFh1o
dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzCBpQYDVR0fBIGdMIGaMEyg SqBIhkZodHRw
Oi8vY3JsLmNvbW9kb2NhLmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhl bnRpY2F0aW9u
YW5kRW1haWwuY3JsMEqgSKBGhkRodHRwOi8vY3JsLmNvbW9kby5uZXQvVVRO LVVTRVJGaXJz
dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBsBggrBgEFBQcB AQRgMF4wNgYI
KwYBBQUHMAKGKmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL1VUTkFBQUNsaWVu dENBLmNydDAk
BggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCIGA1UdEQQb MBmBF3NhbmRv
cnRhbWFzQGhvc3R3YXJlLmh1MA0GCSqGSIb3DQEBBQUAA4IBAQApWC0WiuPN CRCyPf1P/8f/
hBWucrV/M96ytSs4cCVAc+dFjM2vksOG9EeLnoT6QnOX0b597yT+rKlxUwdy B4jhIQQgkQLt
XL7VHSjQuIDJEV9NsaoWIOHYGCxhbpPVDQddTFGRYcSeVl0GlxUOjt59Y6vt LoWovE81zmyU
f9YDUSW/6XRtcZ8z6qla4Z2BhZAyZjwiuhB3w30kDuj+XXseYnhlloek2i8u y7jOidDcxUo/
ijr61QGMWs/R96YkIqlMa0JhGoAD+WpzHhYf6nXL4xCGk24T6ddNgoQVO379 vnAR/VbybVJf
bJg8mzFPqpFgiZWUeDYfv1t77lkZEA20MIIGNDCCBRygAwIBAgIQD4VAu8Pa uziE4suK1I1P
wDANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVU MRcwFQYDVQQH
Ew5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3 b3JrMSEwHwYD
VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1V U0VSRmlyc3Qt
Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDAyMjMwMDAw MDBaFw0xMTAy
MjMyMzU5NTlaMIHfMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAt IFBFUlNPTkEg
Tk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMg b2YgdXNlOiBo
dHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMp MjAwMyBDb21v
ZG8gTGltaXRlZDEVMBMGA1UEAxMMVGFtYXMgU2FuZG9yMSYwJAYJKoZIhvcN AQkBFhdzYW5k
b3J0YW1hc0Bob3N0d2FyZS5odTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALdl
NAgw7qBgqaIAKGh02RxLWnoH85r/AFXQ4WEzM+OzV73kIqHTlFzJs4fd3B9E SsXNQ/AKURHQ
Z2NKX7zTEJ40XjKxGN22PhAwBU11dqTAhXsN8cRokjpz4OZjajbH9qG+80m5 4deaFBd8KENx
2TA0c/YBfQL0BnNKitOV/xKYBHMCP9hK8gKzxFIj2JlOSR7leFVxBjA5cugU uQphpIZJzfuY
4zSAPcsM6EHrgd9qdGc7bjY3CBIHxN/PcNk1MJKrNLB8N3Yjn0beMu7LXCX1 OOWvRNcYX0pK
Dxm94ffnEK5PNd2Xr02on3CVUpCVQdcOiGFOqO2pSQHssgOoNo8CAwEAAaOC AhkwggIVMB8G
A1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBTVwovR 0VLK7cJPf2Jv
pQUxtU9/KTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUE GTAXBggrBgEF
BQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/ MD0wOwYMKwYB
BAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9k by5uZXQvQ1BT
MIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29t L1VUTi1VU0VS
Rmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaG RGh0dHA6Ly9j
cmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1h
aWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2Ny dC5jb21vZG9j
YS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5jb21v
ZG9jYS5jb20wIgYDVR0RBBswGYEXc2FuZG9ydGFtYXNAaG9zdHdhcmUuaHUw DQYJKoZIhvcN
AQEFBQADggEBAClYLRaK480JELI9/U//x/+EFa5ytX8z3rK1KzhwJUBz50WM za+Sw4b0R4ue
hPpCc5fRvn3vJP6sqXFTB3IHiOEhBCCRAu1cvtUdKNC4gMkRX02xqhYg4dgY LGFuk9UNB11M
UZFhxJ5WXQaXFQ6O3n1jq+0uhai8TzXObJR/1gNRJb/pdG1xnzPqqVrhnYGF kDJmPCK6EHfD
fSQO6P5dex5ieGWWh6TaLy7LuM6J0NzFSj+KOvrVAYxaz9H3piQiqUxrQmEa gAP5anMeFh/q
dcvjEIaTbhPp102ChBU7fv2+cBH9VvJtUl9smDybMU+qkWCJlZR4Nh+/W3vu WRkQDbQxggRd
MIIEWQIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0
IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEw HwYDVQQLExho
dHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmly c3QtQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQD4VAu8PauziE4suK1I1PwDAJ BgUrDgMCGgUA
oIICbjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMDAzMTAx
NDIwMDJaMCMGCSqGSIb3DQEJBDEWBBRvz6SdL5PaCEuA+Nx7FiiLZDKaNDBf BgkqhkiG9w0B
CQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZI
hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgdQGCSsGAQQBgjcQ BDGBxjCBwzCB
rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEe
MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVz
ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1 dGhlbnRpY2F0
aW9uIGFuZCBFbWFpbAIQD4VAu8PauziE4suK1I1PwDCB1gYLKoZIhvcNAQkQ AgsxgcaggcMw
ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBM YWtlIENpdHkx
HjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51
c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNh
dGlvbiBhbmQgRW1haWwCEA+FQLvD2rs4hOLLitSNT8AwDQYJKoZIhvcNAQEB BQAEggEAmbLE
Swf3Ls+d39kDClXhNjMeTPQvhPc+8vSDemqQkADcIc16fP8Ut/0mU/qXQ4yj KvFC6ezdR6pC
NnMV5DTyB0uH1MEyvEI9qnKMthXcjbPbMzNkQ1lf9g7mqYRfXZ2Ok7V6pfdM Jy863r8mse/4
ewT50OOWdKiIlh25IZUsD9K+xXWEVghjwLwxLMGExwITFA5vP8T+jhF/y0G4 fkLTUrK1StSP
qfKMlqWs6+dVxSPKqhhBqLRrt9aghy9okZ1P3nqn0pUbLrKXpqW7lEnxEAME 0csKaLPMRoaU
jUxoy+zIITfsBZw+lxYhN4pmL64MaAWzYzhZLuU/c1iTNvzWWAAAAAAAAA==
--------------ms070607060200040907020204--

Re: Execution order of PHP

Bob McConnell wrote:
> From: Auke van Slooten
>
>> In a hobby project I'm relying on the order in which the following
> piece
>> of PHP code is executed:
>>
>> $client->system->multiCall(
>> $client->methodOne(),
>> $client->methodTwo()
>> );
>>
>
> Think about it from the parser's point of view. It has to evaluate
> $client->system to determine the parameter list for multiCall(). Then it
> has to evaluate those parameters before it can stuff their values into
> the stack so it can call the function. But, whether it evaluates the
> parameter list left-to-right or vice versa is implementation dependent.
> I don't believe you can rely on it always being the same unless you
> always use the same interpreter.

I don't mind about the order in which the parameters are evaluated. The
only thing that must stay the same for my code to work as designed is
that $client->system is evaluated before any of the arguments to the
multiCall method. Your explanation seems reasonable to me, but I've been
informed by people that know more about parsers and compilers than me,
that theoretically there is no requirement for this to be true...

After a further education just now, it is possible for a compiler to
parse the entire multiCall right to left, so it will first evaluate
$client->methodTwo(), then $client->methodOne() and only then resolves
$client->system->multiCall. Before evaluating this call, the compiler
can still check whether the number of arguments matches the parameter
list of the function definition.

Anyway, the point is that I'd like to be able to write multiCall
statements like written above instead of doing something like this:

$client->system->multiCall(
array( 'method' => 'methodOne',
'params' => array() ),
array( 'method' => 'methodTwo',
'params' => array() )
);

regards,
Auke van Slooten
Muze

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Execution order of PHP

From: S=E1ndor Tam=E1s

> 2010.03.10. 14:41 keltez=E9ssel, Bob McConnell =EDrta:
>> From: Auke van Slooten
>>
>>> In a hobby project I'm relying on the order in which the following
>>> =20
>> piece
>> =20
>>> of PHP code is executed:
>>>
>>> $client->system->multiCall(
>>> $client->methodOne(),
>>> $client->methodTwo()
>>> );
>>>
>>> Currently PHP always resolves $client->system (and executes the =
__get
>>> =20
>> on
>> =20
>>> $client) before resolving the arguments to the multiCall() method
>>> =20
>> call.
>> =20
>>> Is this order something that is specified by PHP and so can be =
relied
>>> upon to stay the same in the future or is it just how it currently
>>> =20
>> works.
>> =20
>>> If it cannot be relied upon to stay this way, I will have to rewrite
>>> =20
>> the
>> =20
>>> multiCall method and API...
>>> =20
>> Think about it from the parser's point of view. It has to evaluate
>> $client->system to determine the parameter list for multiCall(). Then =
it
>> has to evaluate those parameters before it can stuff their values =
into
>> the stack so it can call the function. But, whether it evaluates the
>> parameter list left-to-right or vice versa is implementation =
dependent.
>> I don't believe you can rely on it always being the same unless you
>> always use the same interpreter.
> =20
> I think it cannot be that the evaluation order of the parameters is=20
> implementation dependent.
> Just think about it:
> $someobject->method($a++, $a++);
>=20
> What will be the result? Or there has to be some directive to tell the =

> parser to evaluate the parameters from left to right or vice versa.
> And if there isn't, in some future release, there has to be.

The result of that line would be undefined in any language I am familiar =
with. I could manually implement a variation in assembler that would be =
safe, but nowhere else. You have too many operations in a row on a =
single variable without adequate checkpoints between them.

Bob McConnell

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Execution order of PHP

Auke van Slooten wrote:
> Bob McConnell wrote:
>> From: Auke van Slooten
>>
>>> In a hobby project I'm relying on the order in which the following
>> piece
>>> of PHP code is executed:
>>>
>>> $client->system->multiCall(
>>> $client->methodOne(),
>>> $client->methodTwo()
>>> );
>>>
>> Think about it from the parser's point of view. It has to evaluate
>> $client->system to determine the parameter list for multiCall(). Then it
>> has to evaluate those parameters before it can stuff their values into
>> the stack so it can call the function. But, whether it evaluates the
>> parameter list left-to-right or vice versa is implementation dependent.
>> I don't believe you can rely on it always being the same unless you
>> always use the same interpreter.
>
> I don't mind about the order in which the parameters are evaluated. The
> only thing that must stay the same for my code to work as designed is
> that $client->system is evaluated before any of the arguments to the
> multiCall method. Your explanation seems reasonable to me, but I've been
> informed by people that know more about parsers and compilers than me,
> that theoretically there is no requirement for this to be true...
>
> After a further education just now, it is possible for a compiler to
> parse the entire multiCall right to left, so it will first evaluate
> $client->methodTwo(), then $client->methodOne() and only then resolves
> $client->system->multiCall. Before evaluating this call, the compiler
> can still check whether the number of arguments matches the parameter
> list of the function definition.
>
> Anyway, the point is that I'd like to be able to write multiCall
> statements like written above instead of doing something like this:
>
> $client->system->multiCall(
> array( 'method' => 'methodOne',
> 'params' => array() ),
> array( 'method' => 'methodTwo',
> 'params' => array() )
> );
>
> regards,
> Auke van Slooten
> Muze

I don't understand the point in a 10 message thread to ascertain the
safety of what you are doing when you already know it is questionable in
practice and that simply breaking the statements into multiple
statements with temporary variables will provide a perfectly good
solution. The work involved in breaking the code into multiple lines
would be a fraction of that contributed to writing to the list. So the
question now is... are you just looking to discuss the merits and
demerits of implementation dependent processing order or do you want
someone to tell you it's ok to write questionable code? Regardless of
the point and what you end up doing, I would add a comment in your code
explaining that the order of function evaluation is important.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Execution order of PHP

2010/3/10 Auke van Slooten :
> Bruno Fajardo wrote:
>>
>> 2010/3/10 Auke van Slooten
>>>
>>> Hi,
>>>
>>> In a hobby project I'm relying on the order in which the following piec=
e
>>> of PHP code is executed:
>>>
>>> $client->system->multiCall(
>>> =A0$client->methodOne(),
>>> =A0$client->methodTwo()
>>> );
>>
>> Can't you call the methods $client->methodOne() and
>> $client->methodTwo() before the call to $client->system->multiCall()?
>> That way, you could store they values in local variables, and then
>> pass them to the $client->system->multiCall(), assuring that those
>> methods are executed before the multiCall(). Something like:
>>
>> $methodOne =3D $client->methodOne();
>> $methodTwo =3D $client->methodTwo();
>> $client->system->multiCall($methodOne, $methodTwo);
>
> Hi,
>
> This is not what I meant. I should perhaps mention that it's an xml-rpc
> client and the method calls are remote method calls. The multiCall method
> gathers multiple method calls into a single request.
>
> The trick I'm using now is to set a private property in the $client->__ge=
t()
> method when the property you're accessing is 'system'. From then untill y=
ou
> call the method 'multiCall', instead of calling the methods (in this case
> methodOne and methodTwo) the client creates a new object with the call
> information (method name and arguments) and returns that. In multiCall al=
l
> arguments are therefor call information objects and multicall creates a
> single request based on that information.

Hmm, you cleared that to me now... If you need to first create the
property "system" and then call a method in that object "system",
can't you do something like:

$client->system =3D null;
$client->system->multiCall(
$client->methodOne(),
$client->methodTwo()
);

I'm not testing these snippets of code, so sorry if I'm getting something w=
rong.

Cheers,
Bruno.

>
> So in your example the client would simply call methodOne and methodTwo a=
nd
> return the results. Then it would try to do a multiCall with whatever the
> previous methods have returned.
>
> regards,
> Auke van Slooten
> Muze
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Execution order of PHP

On Wed, Mar 10, 2010 at 9:54 AM, Bruno Fajardo wrote:
[snip]
> 2010/3/10 Auke van Slooten :
>> This is not what I meant. I should perhaps mention that it's an xml-rpc
>> client and the method calls are remote method calls. The multiCall metho=
d
>> gathers multiple method calls into a single request.
>>
>> The trick I'm using now is to set a private property in the $client->__g=
et()
>> method when the property you're accessing is 'system'. From then untill =
you
>> call the method 'multiCall', instead of calling the methods (in this cas=
e
>> methodOne and methodTwo) the client creates a new object with the call
>> information (method name and arguments) and returns that. In multiCall a=
ll
>> arguments are therefor call information objects and multicall creates a
>> single request based on that information.
>
> Hmm, you cleared that to me now... If you need to first create the
> property "system" and then call a method in that object "system",
> can't you do something like:
>
> $client->system =3D null;
> $client->system->multiCall(
>    $client->methodOne(),
>    $client->methodTwo()
> );
>
> I'm not testing these snippets of code, so sorry if I'm getting something=
wrong.
>
> Cheers,
> Bruno.
>
[snip]

I'm not sure you would want to assign null to $client->system. After
all, __set() might not be defined.

I agree with Rob here. If order is really crucial, then call the
statements in the correct order:


/**
* causes $client to call __get() in order to resolve
* 'system'
*/
$system =3D $client->system;


/**
* You should add some handling here to make sure that
* $system is really an object that implements your
* multiCall() method, and not something else (like null).
*/


$system->multiCall(
$client->methodOne(),
$client->methodTwo()
);

?>



Andrew

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Execution order of PHP

2010/3/10 Andrew Ballard :
> On Wed, Mar 10, 2010 at 9:54 AM, Bruno Fajardo wrot=
e:
> [snip]
>> 2010/3/10 Auke van Slooten :
>>> This is not what I meant. I should perhaps mention that it's an xml-rpc
>>> client and the method calls are remote method calls. The multiCall meth=
od
>>> gathers multiple method calls into a single request.
>>>
>>> The trick I'm using now is to set a private property in the $client->__=
get()
>>> method when the property you're accessing is 'system'. From then untill=
you
>>> call the method 'multiCall', instead of calling the methods (in this ca=
se
>>> methodOne and methodTwo) the client creates a new object with the call
>>> information (method name and arguments) and returns that. In multiCall =
all
>>> arguments are therefor call information objects and multicall creates a
>>> single request based on that information.
>>
>> Hmm, you cleared that to me now... If you need to first create the
>> property "system" and then call a method in that object "system",
>> can't you do something like:
>>
>> $client->system =3D null;
>> $client->system->multiCall(
>> =A0 =A0$client->methodOne(),
>> =A0 =A0$client->methodTwo()
>> );
>>
>> I'm not testing these snippets of code, so sorry if I'm getting somethin=
g wrong.
>>
>> Cheers,
>> Bruno.
>>
> [snip]
>
> I'm not sure you would want to assign null to $client->system. After
> all, __set() might not be defined.

Yes, you're right, Andrew. Setting the property to null is not the
best choice in this case.

>
> I agree with Rob here. If order is really crucial, then call the
> statements in the correct order:
>
> >
> /**
> =A0* causes $client to call __get() in order to resolve
> =A0* 'system'
> =A0*/
> $system =3D $client->system;
>

This was my point too, to create the object before the call to
multiCall(), I just messed my example with the null assignment... :-)
The code you suggested must solve the OP issue.

Cheers,
Bruno.

>
> /**
> =A0* You should add some handling here to make sure that
> =A0* $system is really an object that implements your
> =A0* multiCall() method, and not something else (like null).
> =A0*/
>
>
> $system->multiCall(
> =A0 =A0$client->methodOne(),
> =A0 =A0$client->methodTwo()
> );
>
> ?>
>
>
>
> Andrew
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Execution order of PHP

Andrew Ballard wrote:
> I'm not sure you would want to assign null to $client->system. After
> all, __set() might not be defined.
>
> I agree with Rob here. If order is really crucial, then call the
> statements in the correct order:
>
> >
> /**
> * causes $client to call __get() in order to resolve
> * 'system'
> */
> $system = $client->system;
>
>
> /**
> * You should add some handling here to make sure that
> * $system is really an object that implements your
> * multiCall() method, and not something else (like null).
> */
>
>
> $system->multiCall(
> $client->methodOne(),
> $client->methodTwo()
> );
>
> ?>

I agree with both of you. If you want it ironclad and you cannot change
the API, then this is how I would do it. The point is that I _can_
change the API, but I like how simple it looks. The backup plan is to do
something like:

$client->system->multiCall(
$client->__defer()->methodOne(),
$client->__defer()->methodTwo()
);

The only problem with this is that I'm polluting the $client 'namespace'
with a __defer method. And it looks less clean... :)

Now if the consensus is that you absolutely cannot rely on the execution
order in this case (not for the order in which function parameters are
evaluated, I don't care about that) then I will just change my API and
remember with fondness what I could not have...


regards,
Auke van Slooten
Muze

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Execution order of PHP

On Wed, Mar 10, 2010 at 14:41, Bob McConnell wrote:
> From: Auke van Slooten
>
>> In a hobby project I'm relying on the order in which the following
> piece
>> of PHP code is executed:
>>
>> $client->system->multiCall(
>>    $client->methodOne(),
>>    $client->methodTwo()
>> );
>>
>> Currently PHP always resolves $client->system (and executes the __get
> on
>> $client) before resolving the arguments to the multiCall() method
> call.
>>
>> Is this order something that is specified by PHP and so can be relied
>> upon to stay the same in the future or is it just how it currently
> works.
>>
>> If it cannot be relied upon to stay this way, I will have to rewrite
> the
>> multiCall method and API...
>
> Think about it from the parser's point of view. It has to evaluate
> $client->system to determine the parameter list for multiCall(). Then it
> has to evaluate those parameters before it can stuff their values into
> the stack so it can call the function.

That's not true. It's entirely possible making languages that are lazy
evaluated. Haskell is an example of that.

--=20
Daniel Egeberg

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Execution order of PHP

Op 3/10/10 1:29 PM, Auke van Slooten schreef:
> Hi,
>
> In a hobby project I'm relying on the order in which the following piece
> of PHP code is executed:
>
> $client->system->multiCall(
> $client->methodOne(),
> $client->methodTwo()
> );
>
> Currently PHP always resolves $client->system (and executes the __get on
> $client) before resolving the arguments to the multiCall() method call.
>
> Is this order something that is specified by PHP and so can be relied
> upon to stay the same in the future or is it just how it currently works.
>
> If it cannot be relied upon to stay this way, I will have to rewrite the
> multiCall method and API...

I think you can probably rely on the call order but given no formal spec
for php it's not ironclad - multiCall() will never be called before
methodOne() or methodTwo() because the return values of those are needed to
pass to multiCall() BUT you can't say for sure whether $client->system will
be evaluated before the methodOne() and methodTwo() calls ... looking at
it the code doesn't actually require it, in practice it doubt the engine
will change so dramatically that the call order would change.

but who cares. the code is full of magic, which makes it difficult to understand
and maintain ... fix it so that it's explicit about what it's doing so that
other developers who read it will grasp the concept without having to dig
into your magic methods. this solves the problem of undiscernable magic and
possible issues with resolution order in the future as well (which if they
happened would be a royal PITA to debug, given the magic methods involved)

>
> regards,
> Auke van Slooten
> Muze
>


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Execution order of PHP

You may not care about this, but from a readability perspective, i
think relying on $client->system being as special as you describe, is
not very readable.

If i'd had to read code that does what you describe, i'd be much
happier to see a datastructure be passed as was suggested elsewhere in
this thread, but even more happy to see something like this:

$client->system->specificMultiCall (
multiCallCommandCreate(array(
0 =3D> array('function1', 'f1p1', f1p2'),
1 =3D> array('function2', 'eval:f2p1', 'f2p2', 'f2p3'),
'f2p1' =3D> array('function3', 'f3p1', 'f3p2')
)
);

This structure allows for calling of any chain of methods, the array
returned by multiCallCommandCreate() can be ordered, the root of this
tree is the sequentially ordered integer keys, parameters are parsed
left-to-right as usual.

multiCallCommandCreate() can then set up an array for use by
specificMultiCall(), the one returned by the collection routine for
$client->system.
The advantages of this are possibly some extra readability, but also
some more room for expansion.


On Wed, Mar 10, 2010 at 3:13 PM, Auke van Slooten wrote:
> Bruno Fajardo wrote:
>>
>> 2010/3/10 Auke van Slooten
>>>
>>> Hi,
>>>
>>> In a hobby project I'm relying on the order in which the following piec=
e
>>> of PHP code is executed:
>>>
>>> $client->system->multiCall(
>>> =A0$client->methodOne(),
>>> =A0$client->methodTwo()
>>> );
>>
>> Can't you call the methods $client->methodOne() and
>> $client->methodTwo() before the call to $client->system->multiCall()?
>> That way, you could store they values in local variables, and then
>> pass them to the $client->system->multiCall(), assuring that those
>> methods are executed before the multiCall(). Something like:
>>
>> $methodOne =3D $client->methodOne();
>> $methodTwo =3D $client->methodTwo();
>> $client->system->multiCall($methodOne, $methodTwo);
>
> Hi,
>
> This is not what I meant. I should perhaps mention that it's an xml-rpc
> client and the method calls are remote method calls. The multiCall method
> gathers multiple method calls into a single request.
>
> The trick I'm using now is to set a private property in the $client->__ge=
t()
> method when the property you're accessing is 'system'. From then untill y=
ou
> call the method 'multiCall', instead of calling the methods (in this case
> methodOne and methodTwo) the client creates a new object with the call
> information (method name and arguments) and returns that. In multiCall al=
l
> arguments are therefor call information objects and multicall creates a
> single request based on that information.
>
> So in your example the client would simply call methodOne and methodTwo a=
nd
> return the results. Then it would try to do a multiCall with whatever the
> previous methods have returned.
>
> regards,
> Auke van Slooten
> Muze
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Execution order of PHP

Jochem Maas wrote:
> Op 3/10/10 1:29 PM, Auke van Slooten schreef:
>> Hi,
>>
>> In a hobby project I'm relying on the order in which the following piece
>> of PHP code is executed:
>>
>> $client->system->multiCall(
>> $client->methodOne(),
>> $client->methodTwo()
>> );
>>
>
> but who cares. the code is full of magic, which makes it difficult to understand
> and maintain ... fix it so that it's explicit about what it's doing so that
> other developers who read it will grasp the concept without having to dig
> into your magic methods. this solves the problem of undiscernable magic and
> possible issues with resolution order in the future as well (which if they
> happened would be a royal PITA to debug, given the magic methods involved)

I've decided to rewrite the API so it is more upfront about what it
does. Your argument about readability, when the API is unknown, is a
valid one. It now works like this:

$client->system->multiCall(
ripcord::encodeCall('methodOne'),
ripcord::encodeCall('methodTwo')
);

Thanks for all your input,
Auke van Slooten
Muze

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php