Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65670
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain yahoo.de from 212.82.108.204 cause and error)
DomainKey-Status: good
DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.de;
  h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=ob5qJOx0KKDZnNN/q/mukyLb+8vKa06+X6ZLzknITcXg/5FcdS2GWsAVTzo95FqSZu//xmoxPfymedMyauT1aXKSKP1Lskx4lvVjZX8LS2fwqeowmZsRwdWkKIYqVybarXwys8JYtKCVT9N7kfq0XV8s2bK65DWI+Mqp/D7X/8E=;
References: <CALeP-ExAiAbiAPgtw8Dh_U5BpBtNGB=sGqMpOCzeecE3WrbP5g@mail.gmail.com>
Message-ID: <1360071907.59347.YahooMailNeo@web133005.mail.ir2.yahoo.com>
Date: Tue, 5 Feb 2013 13:45:07 +0000 (GMT)
Reply-To: hakre <hanskrentel@yahoo.de>
To: Charles Sprayberry <cspray.php@gmail.com>,
  "internals@lists.php.net" <internals@lists.php.net>
In-Reply-To: <CALeP-ExAiAbiAPgtw8Dh_U5BpBtNGB=sGqMpOCzeecE3WrbP5g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] SplFileObject::__toString potentially returns false
From: hanskrentel@yahoo.de (hakre)

=0A=0A----- Urspr=FCngliche Message -----=0A=0A> Von: Charles Sprayberry <c=
spray.php@gmail.com>=0A> An: "internals@lists.php.net" <internals@lists.php=
.net>=0A> CC: =0A> Gesendet: 1:56 Dienstag, 5.Februar 2013=0A> Betreff: [PH=
P-DEV] SplFileObject::__toString potentially returns false=0A> =0A>T here w=
as a previous discussion on the return value of=0A> SplFileObject::__toStri=
ng being=0A> an alias to SplFileObject::current() but that was about the de=
sign decision=0A> why and not=0A> really suggesting any kind of change or a=
 technical error. In the=0A> discussion it was=0A> established that:=0A> =
=0A> (1) Changing this would be a BC break=0A> (2) It isn't really a bug in=
 the codebase, the docs were just wrong=0A> =0A> The current implementation=
 has a bug in that current() can potentially=0A> return false, if=0A> false=
 is returned from the __toString() magic method a catchable fatal=0A> error=
 occurs.=0A> [...]=0A> I would say that SplFileObject:__toString() being an=
 alias to=0A> SplFileObject::current()=0A> makes the use cases for the meth=
od very limited and that the current=0A> implementation is=0A> mistaken in =
returning current(). I can think of no use case where=0A> SplFileObject::__=
toString()=0A> should return this value. If need to get the current line yo=
u're probably=0A> iterating and in=0A> that case should be using foreach() =
and don't really need to manually take=0A> care of that.=0A> Even if there =
is a use case for manually invoking=0A> `SplFileObject::current()` you prob=
ably=0A> aren't casting a string in that situation and a more expressive me=
thod call=0A> is better.=0A> =0A> (1) Leave the implementation the way it i=
s and simply return a blank string=0A> when=0A> current() would return fals=
e=0A> =0A> (2) Change the implementation to return SplFileInfo::__toString(=
)=0A> =0A> (3) Change the implementation to return entire file contents=0A>=
 =0A> (4) Return some other unthought of string but remains consistent and =
logical=0A> =0A> I am personally partial to (2) or (3) perhaps in 5.5 but (=
1) could probably=0A> happen=0A> sooner? Thoughts?=0A>=0A=0AI often use thi=
s object. A few things I can notice:=0A=0A- In practice I never ran over th=
is error. Mainly because I use `foreach` rather than the object itself in s=
tring context to obtain the line(s).=0A=0A- Even I did not run into a concr=
ete problem, I would consider this a bug because the object itself is viola=
ting the __toString() interface. When I get that error with my own code, I =
always consider this a bug and fix it. So this should be fixed in PHP core =
code when I keep myself as a mark.=0A=0A- Because SplFileObject is a subtyp=
e of SplFileInfo, it should return the same for the same interface, e.g. `_=
_toString()` must return the same type of value as of SplFileInfo to not br=
eak the substitution. Only the more specific parts of the interface are all=
owed to offer more specific behavior. Right now it violates LSP. This shoul=
d be addressed and fixed behaving exactly like SplFileInfo.=0A=0AIMHO fixin=
g all these flaws require a BC break which I would consider something good =
in this specific case. So I welcome a BC break as soon as possible so that =
in the future functions accepting a SplFileInfo also work with SplFileObjec=
ts if they make use of the string context.=0A=0AUntil then, a workaround is=
 to provide your own subclass of SplFileObject that overwrites `__toString(=
)` again. Maybe this is something useful for projects that make use of the =
SplFileObject already.=0A=0A-- hakre