On Apr 12, 2004, at 3:06 PM, Sterling Hughes wrote:
It is. It's a hardocded portion of their app, and they made a mistake. They may not care, but it's also possible that they do. Assuming that they don't care enough to fix it seems equally crazy to me.
Could be a version mismatch with tidy, and a newer library. They develop there code, the option exists, and then someone with an older version of the library doesn't have that. Whether or not i have 4 spaces or 2 in my output is rather inconsequential. Now you deploy somewhere else and this explodes somewhere within a function and bumps the script out of a critical execution context and refuses to work.
Setting an option has semantic meaning. Whitespace has no semantic meaning in PHP. These are apples and oranges.
Rewind to the beginning of the discussion, the scope is not as broad as you claim.
I did. fast-forward to the end of this message, that's exactly the point john brought up.
He's talking about all E_WARNINGs in an OO context, not in an OO extension.
I could, I could also catch my exceptions. There are plenty of other exceptions (casting errors, etc) that will irk me whenever I use Python.
I've probably written a considerably large amount of python and I haven't run into this rampant exception problem you talk about. Could also be the reason why I like Python more than you... ;) It makes sense that overloads would cause exceptions, as it does with type casting exceptions - remember, python is a strongly typed language, that type schiznizzle is important to them.
I'm not arguing whether it's important to them. I'm arguing that things that are not important to my app generate exceptions in Python. Something can be important in a language but not important to my app.
Either i'm missing the point or we are agreeing this shouldn't be so.
You were saying that not doing this was consistent with other languages. I was saying that it was not.
Ok, then we disagree. I think its entirely inconsistent because the two systems don't map to each other, and you get plenty of cases where the two simply don't map. John is talking about *all* E_WARNINGs in OO code, and in the procedural variants, sending E_WARNINGs. The scope of E_WARNING is not in my opinion the same scope as an exception in any language, and we may just have to agree to disagree.
The not-mapping issue is a serious one. PHP's procedural error-handling does not map well to Java or Python. PHP's OO error-handling can. The former can't change, the latter can. I don't think there's a clean answer. And before I incur a rant from Sascha about how I ramble endlessly without point, I'll resign from this argument.
George
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
