3 ms·
> No, Java is not the same. Scalars not objects in Java and are passed by value. How are pass-by-value and pass-by-object distinguishable for immutable values?
by eevee 14y ago
> No, Java is not the same. Scalars not objects in Java and are passed by value.
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?
- wvenable 14y ago> How are pass-by-value and pass-by-object distinguishable for immutable values? They aren't really. There's no real technical difference, just a terminology difference. All that you need to know is that whether it be Python, PHP, Java, or whatever that passing around scalars and objects works out the same. > 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 never said anything about functions -- just that the cast itself is useful. > 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. People cast objects to arrays in PHP all the time because that can be a useful operation. I understand you point, but I don't really think it's too valid. If you're explicitly doing a cast, you should know what you're casting from. This is sound advice no matter what language you're using. > strictly speaking Python isn't interpreted, whereas e.g. shell is. It's an implementation detail that's not significant. The next version of bash should byte-code compile everything behind the scenes and run it (like PHP does) and it wouldn't make any difference. You could write an interpreter for C code (they exist) and it wouldn't change anything about C. > Note that, for the same reason, you also can't chain calls like `foo()()`. Honestly, there's no language grammar reason why that shouldn't work in PHP. It's just that parser sucks and they're very slow/careful to make changes to the parser. If it's a function name, a closure, or an object that supports being called they're called the same. If you can do $foo() then you should be able to do foo()(). The same is true about foo()[]. These things don't have to special-cased so much as the parser has to be modified to be more generally accepting. > What language are you thinking of where there's a distinction made -- in the parser, no less -- between a variable and an expression? PHP makes no distinction between a variable and an expression (except as described above). It's make a distinction between scalars and objects. > Sure, why not? Not that I was suggesting PHP direly needs scalar methods, but if a number responds to strlen(), why not to ->strlen()? Then there's really no point in having scalars be objects. You could add syntactic sugar to make strlen($x) and $x->strlen() do exactly the same thing but what would be the point? I'd rather they do something more interesting with that ability. I think it's the only way they can successfully implement unicode. > 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. MySQL made this decision, not PHP. They just give you the library to use. Anyway, you seem to have a problem with the concept of backwards compatibility -- it generally does mean "continue to use this broken thing because you don't want to change your code". > I'm hearing this a lot, but (as far as I can be trusted to say this) I don't see it. Someone tells you that you lack perspective and you don't see it -- so ironic! (I'm just being cheeky) > 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, but going off on public/protected/private as if it's a flaw in PHP because you don't like them is not a valid critique. That's just one example but there are others. Even saying everything should be an object is more personal taste than anything else. I very much like "everything is an object" but it's not clear how best to implement that in PHP yet. > 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. I disagree. I think I probably switch between languages a bit more than you do and the little things don't matter that much. What matters is the big things. Most of the stuff you mention in your article, if I encounter them at all, I don't even notice. It's such a non-issue that unless you bring it up, I wouldn't think to tell you. In fact, in some cases, I wasn't even sure what you were talking about because I don't encounter them (the lack of stack traces on errors, for example). > I've heard a lot of defenses and a lot of statistics, but not too many outright advantages. Indeed. I'm not saying PHP has advantages over other platforms -- it has some -- but, in the end, the differences between any of the platforms aren't significant and mostly personal taste. I continue to code in PHP because I know PHP, I know the frameworks, and I have lots of existing PHP code. If I had to write Python or Ruby, I would. I'm going to be writing ASP.NET code for next 6 months. I just think your article blows everything out of proportion. Much of it is "look how this crazy unreasonable code reacts in PHP". It's not invalid but it's not really indicative of developing in PHP. Similar lists have been made for JavaScript and yet that doesn't affect opinions too much. Similar lists have been made for C and C++ but everybody knows what they're getting into there. Here we are talking about mysql_real_escape_string() and that's as legacy as you can get.