Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65518
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH-PCH66RjYJdL7tW_Lh0itDvWt+JPjQtaXHJNy10Eus3rj88Q@mail.gmail.com>
References: <1359498582.20362.YahooMailNeo@web133002.mail.ir2.yahoo.com>
	<51085497.3090504@sugarcrm.com>
	<1359560655.44471.YahooMailNeo@web133004.mail.ir2.yahoo.com>
	<CAH-PCH7+78tCr=O+4PvKvb6-7SbALgOCgPmekzCjTA+o28k5iw@mail.gmail.com>
	<51096387.3030909@sugarcrm.com>
	<CAH-PCH66RjYJdL7tW_Lh0itDvWt+JPjQtaXHJNy10Eus3rj88Q@mail.gmail.com>
Date: Wed, 30 Jan 2013 18:48:14 +0000
Message-ID: <CAKxcST-zpfrdKvnDnROfsWtP7OVio3LJjHuT+Gg+0bR1FpFbxA@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, 
	"internals@lists.php.net" <internals@lists.php.net>, hakre <hanskrentel@yahoo.de>
Content-Type: multipart/alternative; boundary=047d7b6d9f1ce1ba9904d485f331
Subject: Re: [PHP-DEV] echo new SplFileObject(__FILE__);
From: dragoonis@gmail.com (Paul Dragoonis)

--047d7b6d9f1ce1ba9904d485f331
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I also agree that we don't need to fix this, nor break BC. It is confusing
as hell but it's there now and changing it would be more disruptive.

Is there a desire from anyone to gracefully throw E_DEPRECATED in a future
version of PHP 5.x when someone tries to __toString() the SplFileObject but
only get back a single line ?

That's the only "plan forward" I can see feasible if we decided to do
anything, otherwise we should move on.


On Wed, Jan 30, 2013 at 6:44 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:

> 2013.01.30. 19:16, "Stas Malyshev" <smalyshev@sugarcrm.com> ezt =EDrta:
> >
> > Hi!
> >
> > > But this isn't that strong of an argument, and I think that following
> > > what SplFileInfo does would be more sensible (echoing the filename),
> but
> > > I'm not sure change would worth breaking BC for.
> >
> > I don't see why it would be more sensible. It's different objects that
> > do different things - Info represents file name, more or less, while
> > Object represents file contents. I see no reason why it would only make
> > sense for Object to return filename, or why we should "fix" something
> > that is not broken.
>
> imo the toString should return something which represents the object and
> the filename satisfy that better than a "random" line from the file.
> but I agree that this isn't a real concern and doesn't need fixing.
>
> > --
> > Stanislav Malyshev, Software Architect
> > SugarCRM: http://www.sugarcrm.com/
> > (408)454-6900 ext. 227
>

--047d7b6d9f1ce1ba9904d485f331--