[TYPO3-core] good question

Kasper Skårhøj kasper2005 at typo3.com
Thu Dec 15 17:34:00 CET 2005


Yes, this strange construction was done in order to resolve any variable 
references in the process of copying TypoScript chunks. Basically the problem 
was that if someone did like:

page.10 = TEXT
page.20 < page.10
page.10 >

.... then internally page.20 would be a reference to page.10 and therefore 
both page.10 and page.20 would be deleted when page.10 was unset. Or another 
porblem: 

page.10 = TEXT
page.20 < page.10
page.10 = HTML

... then page.10 would also change page.20 because it was a reference.

BUT when I serialized/unserialized this would go away. I introduced this from 
PHP3 to PHP4.

My problem is this: Above I have explained that the problem was _something_ 
with references but I remember that it was only in some rather exotic and 
hard-to-find case that it failed. This means; If we change this we might not 
encounter problems before someone reports strange errors we don't believe he 
actually has - and that will create lots of confusion. To make a change we 
MUST create some UNIT test which tests all and can validate that maybe today 
PHP doesn't need this. Until then I'm for keeping it although it looks 
obscure...

- kasper



On Saturday 26 November 2005 16:42, Michael Stucki wrote:
> Hi Bernhard,
>
> > May somebody tell me what is the sense of the
> > "unserialize(serialize(...))" in this line:
> >
> >                     $this->setVal($objStrName
>
> $setup,unserialize(serialize($res)),1);
>
> > (line 289 of class.t3lib_tsparser.php)
> >
> > It seems as it does nothing except wasting cpu cycles :)
>
> I agree. I just checked: This has been there since CVS rev 1.1 so I suppose
> it was written by Kasper. Maybe he can explain?
>
> - michael

-- 
- kasper

-----------------
"A 'please' would be nice", John Travolta, Pulp Fiction



More information about the TYPO3-team-core mailing list