Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51597
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.22 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "internals@lists.php.net" <internals@lists.php.net>
References: <43.60.54597.484527D4@pb1.pair.com> <op.vrv0tjvjidpuyk@cataphract>
 <4D7436E8.7010802@sugarcrm.com> <op.vryung0uidpuyk@clk-0081.clk-domain>
 <4D74A2E0.3090304@sugarcrm.com> <op.vryvs9h6idpuyk@clk-0081.clk-domain>
 <4D74AAA3.9020307@sugarcrm.com>
Date: Mon, 07 Mar 2011 10:06:47 -0000
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_I=2ES=2ET=2E?=
Message-ID: <op.vryw1kgkidpuyk@clk-0081.clk-domain>
In-Reply-To: <4D74AAA3.9020307@sugarcrm.com>
User-Agent: Opera Mail/11.01 (Win32)
Subject: Re: [PHP-DEV] [patch] allow socket_[gs]et_options() to work on
 streams
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

Em Mon, 07 Mar 2011 09:51:31 -0000, Stas Malyshev <smalyshev@sugarcrm.com>  
escreveu:

>> I suppose this information could be queried, but would you want to do  
>> the cast and retrieve this data in every call say in a socket_read loop?
>
> I'd ask why you need socket_read and not just fread if you use streams?  
> If you need deeper semantics, then yes, either you use resources or you  
> convert. I'm not against the conversion function, per se, but the  
> regular API shouldn't force it's use (see below).

That's a misleading argument. I could write a function that expects a  
socket resource and it would still work if passed a stream, but with  
degraded performance and functionality.

The degraded functionality comes from the fact socket_last_error() could  
no longer be used to retrieve the last error on the socket as PHP streams  
don't save this information. There may be other issues I'm not aware of.

> We don't have alternative to setting socket options on a stream. Neither  
> we want one - why have two functions for doing the same thing?

Because the sockets extension is not enabled by default and it has a  
different design -- it provides a low-level interface that closely follows  
the C interface. Compelling functionality should still be added to the  
streams, hopefully with a friendlier interface than socket_set_option.

-- 
Gustavo Lopes