Hello Andi, the excepton part is not in it jet but i'll do it (or dmitry can do it easily). However i don't see a point here. And i don't see a point in your dtors either. If anything that happens with the current implementation of the patch is wrong then either it is an edgecase we have to fix or it would have happened with __get/__set/__call as well which use the exact same ideas besides the fact that they are called for different reasons of course. That said i again don't see any reason to wait unless someone can show something that is causing a real problem and not something that eventually might effect some unknown parts in a way that theoretically might be bad.
p.s.: you often enough said gimme some time and we just lost things. Tuesday, September 27, 2005, 2:17:55 AM, you wrote: > Marcus, > I think you misread my email. > I said that it *should* be commited. I did want an additional two > days to review because we did *have* feedback for the patch (as you > saw). I don't know who "All others" are, but I don't know many who > can understand this patch to the lowest level of details. > So I don't know where you got the idea of blocking. Let me quote > myself "I think we should then commit to HEAD"... > That said, although many are trigger happy, I am noting that > architecturally, this has far reach implications (it will reach > everyplace in the engine which does a convert_to_*() etc.). I > apologize that I can't pinpoint a precise problem right now (such as > convert_to_* being called after dtors are called). All I tried to say > is that we have to be aware that this is a very sensitive area to > change and there is a good chance we might bump into problems. > So as I said in the conference and in my email, I'm not against > progress, I am just stating we need some time to make sure that it's > indeed progress and doesn't regress us into trouble. That's why we > need (and have) enough time to make sure things don't break ala > exceptions not propagating everywhere or changing behavior of return > by reference. One problem I pointed out which had to do with > exceptions not propagating from __toString() was very valid, and we > agreed to not allow it (did you actually implement that part of the > discussion?). > Believe me, from a usability perspective, I think __toString() > working automagically is very nice... I'm just being less trigger > happy and want to make sure we're covered. > Andi > At 10:05 AM 9/25/2005, Marcus Boerger wrote: >>Hello Andi, >> >> i don't see your point here. We've discussed this tons of times. Either fix >>the engine if you know it's broken, show us a real problem with the pacth or >>accept the fact that we want to make progress here. Blocking patches because >>they have a slight potential in causing some problems without telling about >>the problems and coming up with some test script doesn't help anybody here. >>You are just waisting my time with that. All other who saw the patch agreed to >>it already. >> >>marcus >> >>Sunday, September 25, 2005, 6:31:59 PM, you wrote: >> >> > Give me a couple of days to review the patch itself. >> > I think we should then commit to HEAD, and see how it goes. There's >> > hopefully enough time in the PHP 6 process to validate that this kind >> > of patch doesn't hit any conceptual problems re: propagating to >> > pre-compile/post-shutdown execution stages... >> >> > Andi >> >> > At 05:36 AM 9/25/2005, Marcus Boerger wrote: >> >>Hello internals, >> >> >> >> the patch implements __toString to have obejcts be >> automatically converted >> >>to strings anywhere a string is requested. We have talked a lot about this >> >>in the past and during OSCON Andi agreed again on it and said that the HEAD >> >>version of the engine should be ready for it now. Futher more we >> have enough >> >>time to fix any outstanding engine issues regarding this. >> >> >> >> http://php.net/~helly/php/ext/ze2/ze2-tostring-20050925.diff.txt >> >> >> >> If nobody objects with a real technical issue i'll commit the >> patch early >> >>in the week. >> >> >> >> The patch is a little big longer because it ensures that __toString gets >> >>treated and especially gets cached just like any other magic function is. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
