How are pass-by-value and pass-by-object distinguishable for immutable values?
> That's not what we were talking about.
Yes it is. You said (array) as a cast is useful because a function can accept either a single value or an array of values, and the (array) cast will produce an array either way. I contend that doing this doesn't really work, because passing a single value that happens to be an object will cause the function to cast it to an array of the object's contents, which will have fascinating but useless results.
> You cited byte-code interpreted as if that's somewhat significant.
I only mentioned bytecode for the sake of pedantry: strictly speaking Python isn't interpreted, whereas e.g. shell is.
> You could read the manual.
I had to do quite a lot of that. It's kind of wordy. :)
> Most languages make the distinction. Why shouldn't there be? That's really ugly code.
I'm not proposing that people write code like this. I'm objecting to the inconsistency between a value in a variable and a value in source code.
Note that, for the same reason, you also can't chain calls like `foo()()`. There ARE good reasons for that: you could return a function name, or a closure, or an object that supports being called. But because the parser doesn't just allow trying to use parentheses on an arbitrary value, this doesn't work. Just like `foo()[]` didn't work until recently, because it too had to be special-cased.
> That's fine. It doesn't mean every language should do the same. Most languages, especially those PHP is based on, do not do that.
Really? C doesn't have methods. C++ has methods, but string literals are C strings so they have no methods. Perl doesn't consider builtin types to be objects, but if you turn them into objects with `autobox`, methods work equally well on variables and literals. Python allows method calls on literals -- and will let you try to call them, but of course literal strings aren't callable so this won't do anything. It parses, though. Ruby is the same. "foo".equals("bar") is a common Java idiom.
What language are you thinking of where there's a distinction made -- in the parser, no less -- between a variable and an expression?
> Maybe one day PHP will have that but because it's weakly typed, it's difficult to know even what methods should exist. In PHP, it's perfectly reasonable to say strlen(1). Does that mean every number should have string methods? I'm guessing you never considered that?
Sure, why not? Not that I was suggesting PHP direly needs scalar methods, but if a number responds to strlen(), why not to ->strlen()?
> Yes, because the encoding properties of the current database connection are needed for encoding properly. If have two database connections, then what?
Then you're screwed no matter what Zend does and still need to fix your code. So the options were: 1. Leave the existing function totally broken. Create a new one with a confusing and even longer name. Make everyone fix their code and remember to use the new function in the future. 2. Fix the issue in-place for the vast majority of existing code. Make the edge cases fix their code by doing the same thing they have to do with every other API function anyway. Optionally, throw a warning when multiple handles exist and mysql_escape_string is called with only one argument.
What, then, is the appeal of (1)?
> You've got a very singular perspective on things. That's fine. But by critiquing another language without knowing it you're making a lot of assumptions and blowing things way out of proportion.
I'm hearing this a lot, but (as far as I can be trusted to say this) I don't see it. I draw a lot of comparisons to Python and Perl because they're in the same family and I know more about their inner workings than anything else. That doesn't mean they're the only languages I've used or the only languages I think are worthwhile.
Yes, I picked on a lot of little things. It's the little things that matter. Every language (ahem, most) has function calls, data structures, and loops. What differentiates them is the little day-to-day stuff.
So what am I missing? What makes these design decisions good, what makes PHP great? I've heard a lot of defenses and a lot of statistics, but not too many outright advantages. Most of your original response is just workarounds, not reasons why the behavior is good or even acceptable. The image I'm left with is that of an overgrown playground filled with active mines, but most of the mines have upturned buckets over them so you probably won't step on them, and that's supposed to make it a great place to send your kids. If even PHP's supporters can do no better than explain how to write passable PHP when I have a gun to my head, why would I want to use it?