Hi! > this is where my point about we allow serializing resources just fine > was aimed at.
It's not "just fine". It's "it was there before we got smarter so now we can't change it without breaking too many things". But I think we did get smarter and no longer see silently putting whatever string in place of object while serializing as an acceptable method of serializing. > nobody suggested replacing Exceptions with integers, but serializing > Closure to "Closure #1" or similar (albeit we could even do a better > job, similarly how java8 supports lambda serialization). It's not "serialization" in any meaningful sense. It's replacing an object with a useless string value, silently, hoping the user didn't actually need it. If you didn't actually need it, why waste space serializing it at all? And why not to tell the user we can't actually serialize it? > var_export() shares the same problem, should we then also try to remove > __toString() from closures? toString is not serialization. toString is producing human-readable string representation - its very definition implies you lose all object identity and receive only string. It is completely different thing from serialization. Serialization is supposed to preserve the object so it can later be restored. Replacing object with toString() is in no way serialization. > should give more rope for the developers to hang themselves but the > current situations sucks (you can serialize basically anything And we have tons of problems with serializing "basically anything", including a smorgasbord of security issues, because of that. Because of trying to unserialize objects that weren't supposed to be even serializable. > Closure) and I think that your suggested way of solving the problem > would create a medium sized BC break for little gain as it would only The gain is that we get rid of those issues and also get people to understand what serialization means (as I said it's not "put an object, get a random string out" and it's supposed to be two-way, not one-way). Yes, that means some objects could not be serialized. They *should not* be serialized, and the fail should be explicit, not in the form "suddenly I get string instead of object", or, even worse, "my app crashes randomly when I unserialize complex objects because somebody stored unexpected object in a property". > that's true, but you would only remove a single attack vector via > removing an otherwise useful feature I disagree with serializing exceptions being "useful feature", and "removing a single attack vector" is one attack vector less. Its not like we can either remove all attack vectors at once (which as we both know is impossible) or never remove any of them. Removing them as we identify them is how we can do it. If we can remove a whole class of them instead of trying to fix a feature of no practical use that already proven to be source of trouble, it looks like a win to me. > BTW what you mean by "unserializable Closure"? As far as I know you can > not serialize Closure. > > > I mean exactly that and btw. that was the original problem in the Well, if you mean serializing closure then you still can't do that. And I see no reason why you should be doing that. > Stackoverflow post you cited in your opening post > (http://stackoverflow.com/questions/9747813/storing-a-php-exception-object-in-a-database). I know. Serializing exceptions and storing them in the DB is *not* a good way to do logging. And us taking stance "well, just serialize stuff and we'll throw in whatever strings there instead of objects" encourages this wrong behavior. That's exactly what we need to fix. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
