On Wed, Mar 11, 2020, at 4:57 AM, Nikita Popov wrote:
> On Tue, Mar 10, 2020 at 5:19 PM Côme Chilliet <
> come.chilliet@fusiondirectory.org> wrote:
>
> > Le mardi 10 mars 2020, 15:53:41 CET Nikita Popov a écrit :
> > > Would __toString() return $token->text? I'm not strictly opposed to this,
> > > but I'd be hard pressed to think of a situation where I would prefer
> > > writing (string) $token over $token->text. Generally, the less magic the
> > > better :)
> >
> > My idea was that since tokens are parsed from a string it should be easy
> > to write a string back with them.
> > I do not have an obvious usecase but the idea is doing stuff like
> >
> > if ($token.is('function')) {
> > echo "public $token";
> > } else {
> > echo $token;
> > }
> >
> > Am I right to assume that with __toString the same as ->text we’d have
> > implode('', PhpToken::getAll($code)) == $code ?
> >
> > This would allow:
> > $tokens = PhpToken::getAll($code);
> > // Modifications on $tokens
> > $code = implode('', $tokens);
> >
>
> Yes, that would work. It's not much harder without __toString though:
>
> $code = implode(array_column($tokens, 'text'));
>
> Does anyone else have thoughts on whether PhpToken should implement
> __toString() or not?
>
> Nikita
I forget who it was but someone on the list a while back offered a heuristic of "__toString should be used iff there is one and only one logical string representation of a value, because the value is conceptually just a string with extra metadata on it".
That sounds like a really solid heuristic to me. In this case, I think yes, ->text is the only reasonable thing to produce for __toString().
Or perhaps this is a good use case for "you can use a subclass, do that" if there's any good reason to not have it just be ->text.
--Larry Garfield
