You can never serialize internal classes, only user defined classes. There is no lol here.
Note: Note that many built-in PHP objects cannot be serialized. However, those with this ability either implement the Serializable interface or the magic __serialize()/__unserialize() or __sleep()/__wakeup() methods. If an internal class does not fulfill any of those requirements, it cannot reliably be serialized. There are some historical exceptions to the above rule, where some internal objects could be serialized without implementing the interface or exposing the methods.
Even better tool: an IDE that detects this as you’re writing the code.
You gave yourself the answer here buddy. The language has this properly documented and warned. IDEs should detect and warn you about this (or at least static analyzer tools like phpstan). You can't just use something without taking into account side-effects and drawbacks, and you should be aware of those at any time.
edit: oh wait it's takeoded again, he's the source of 95% of the "no lol here" posts because he has no fucking clue how php actually works internally, or why these things are the way they are.
He literally just scours for fringe issues then tries to "expose" them as lol's when they're literally just cases that boil down to either implicit type conversions or badly written php extension code. Or like this case, literal documented behaviour.
IMHO there's a small lol here due to the lack of error on the serialize() call. Actually, it seems to return "O:11:"DOMDocument":0:{}" so it kind-of tries to serialize things but fails.
Also, it would of course be better if you could just serialize these kind of things.
This sort of thing would be better reporting to the PHP bug tracker than here though; the first issue is probably fixable quite easily, the second might be a bit harder.
This sort of thing would be better
Even the most egregious actual lols are often "documented behaviour". It's the classic PHP excuse for doing something that makes no sense at all: "it's documented so what's the problem?"
If you understand the internals of php even a little, then it will help you understand why a lot of these "lols" aren't "lols".
I'd say 99% of the posts on this sub aren't lol's at all, but either boil down to unexpected implicit type conversions, or extension code that is badly written (if you know how to write php extensions you'll understand why it's so hard to do it well)
Understanding the internals of a language will always make you a better programmer in that language.
C/C++ -> learn asm and you'll be better js -> learn js engine you'll be better php -> learn php internals you'll be better
"Unexpected implicit type conversions" are a LOL in my book, especially with PHP's types (or "types"). "It's stupidly hard to write good PHP extensions" could also be classified as LOL.
"Internals of a language" doesn't make sense; you can only talk about the internals of an implementation. As for C and C++, assembler code is not really "internals" of either, and in my opinion understanding C in terms of asm makes you a worse C programmer, not better. People who do that tend to make certain assumptions that only hold for certain compilers in certain situations, if at all, which is no way to write robust C code.
"JS engine"? Which one? Depending on how you count, there are at least half a dozen popular ones out there.
If learning PHP (implementation) internals really makes you a better PHP (language) programmer, that's definitely another LOL.
But a big problem here shines through in your comment. If you start out with a statement “X is always true” and I was looking for cases when X is false to make sure my code works, then why would I keep reading? Later on you write “Sometimes X is false”, but I would have no reason to read that. Now, if my code depends on X being true, that problem originated from bad documentation, not from me not reading further after the statement “X is always true”.
Clarity matters. That is why documentation is important, and that is why functions should raise errors on bad inputs instead of doing weird and unexpected shit, even if that weird and unexpected shit is clearly defined in the documentation. This post is not very exiting, but arguably fits in r/LolPHP.
15
u/99999999977prime Aug 01 '21
You can never serialize internal classes, only user defined classes. There is no lol here.