Earlier quoted context omitted.
I prefer Javascript for example: JQuery's calling conventions would not be possible if function args were mandatory.
You can always use func_get_args() if you truly want it that way.
These are things in PHP which make me sad
171–180 of 217 posts
Re: These are things in PHP which make me sad
#172What makes ME sad is no keyword arguments. Helper/wrapper functions either get an annoying and difficult-to-grok-at-glance associative-array for it's params (bad), or a huge list of rarely-used parameters (worse), or a huge set of wrapper functions to set their own paramters (even worse), or outright duplicated functions for similar-but-not-quite tasks (worst). This happens to me while producing something like a jqGr…
You can use the @ symbol to suppress errors when you're aware that the variable may be empty and you've considered the possible effects. When I used to write PHP, I'd often write something like do_something(@$_GET['foobar']); There are ways to suppress PHP notices without just turning off the E_NOTICE output.
Instead, I use a 'get or else' function, as in some functional languages. For arrays, it goes
function get_or_else($array,$key,$default=null)
{ return isset($array[$key]) ? $array[$key] : $default; }
This avoids any warnings, and also allows you to specify a default.Re: These are things in PHP which make me sad
#173Earlier quoted context omitted.
Also, the days of PHP's deployment superiority are nearly over. So I've been hearing since 2000 or so, when I chose RXML/Pike over PHP because PHP was a complete mess. PHP has gotten considerably better since then; now it's only painfully messy, rather than unusable. Sometimes it seems like every competitor has been busy building castles in the sky full of magic and wonder -- as long as you want to do exactly what th…
> Wow, what an achievement! This is the one thing that PHP really, seriously got right: no application server. I think you mean PHP has no 'apparent'. It damn well does have an application server, it's called mod_php embedded in Apache processes or php-fcgi backends. The thing is, that PHP apps DO fail after a certain number of requests, it's just hidden from you. Internally PHP ships with a MAX_REQUESTS (which defau…
Re: These are things in PHP which make me sad
#174Earlier quoted context omitted.
You missed the point: they are talking about people who do not know those aspects of the LAMP stack, not the ones who can afford delegating them to DBAs and sysadmins. The first group are indeed glorified web page editors.
Again, bullshit. I've had PHP projects that were entirely command-line with no Apache and MySQL. If you want to argue that those projects weren't development, that's absurd. Systems and database administration are hugely complimentary skills, but someone who doesn't know anything about setting either one up is still developing.
Re: These are things in PHP which make me sad
#175PHP is Open Source. Compiling a list like this is nice, but contributing something back, and getting involved in making improvements to PHP, would be nicer.
The core team has it's own priorities, and has a history of ignoring the requests of the dev community. A couple of examples: in version 5.3, they added `goto`. WTF. Who, after five major releases, decides that what a language really needs is `goto`. In the same release, they decided to finally add namespaces. But, despite the tired claim that PHP takes cues from C/C++/Java, they did not reuse :: (aka paamayim nekudo…
> Who, after five major releases, decides that what a language really needs is `goto`.
It makes it a much easier compilation target.
> But, despite the tired claim that PHP takes cues from C/C++/Java, they did not reuse ::
They couldn't because unlike C/C++/Java the entire project isn't compiled at once. At compile time, PHP has no idea that the symbol preceding the operator is a class name or namespace from one run to the next. It might have been possible to resolve that with major changes to the underlying engine or maybe not. I absolutely hated the idea of the backslash when proposed but after using it for a while it seems fairly comfortable.
Re: These are things in PHP which make me sad
#176Earlier quoted context omitted.
What would the ideal language return for your function call foo('bar'). It would seem to me that missing an argument should return some sort of notice, like in the case where someone else is using it.
I prefer Javascript for example: JQuery's calling conventions would not be possible if function args were mandatory.
Re: These are things in PHP which make me sad
#177Earlier quoted context omitted.
Yeah, I understand the cause. Just because those steps make logical sense doesn't mean it's not a bug. My real point was about the WONTFIX tendencies of the PHP dev team at the time (I've been gone a while; maybe it's better now). It's absolutely the thing I miss least about that community. I mean, when I filed that bug PHP 5 -- the first version to support foreach with references -- was less than 2 months old. The "…
It's not a bug because it's not a bug. How would you propose they fix this non-bug anyway? At the end of the first loop, $item contains a reference to the last item in the array. Just as $item would contain the value of the last item in the array if you weren't using references. In the next loop, $item still contains that reference so now you're overwriting the value of that reference. You can't assume the second loo…
I think you should pause for a minute and summarize all of the WTFs you've rationalized on this post. Just the volume of it makes me incredulous that you don't think PHP == FAIL (or perhaps === if you like).
Re: These are things in PHP which make me sad
#178Earlier quoted context omitted.
> Wow, what an achievement! This is the one thing that PHP really, seriously got right: no application server. I think you mean PHP has no 'apparent'. It damn well does have an application server, it's called mod_php embedded in Apache processes or php-fcgi backends. The thing is, that PHP apps DO fail after a certain number of requests, it's just hidden from you. Internally PHP ships with a MAX_REQUESTS (which defau…
Well, if you're considering Apache+plugin to be an application server, then I guess I need to say: no additional application server other than the web server. Most modern systems have a web server and a separate process for the application server (proxied to over HTTP or fed by FastCGI or WSGI or a neat otherwise unused protocol). The standalone application server (back when I was mostly using those languages) always…
I agree that what you could call it's deployment API (or whatnot), that it is very simple. I think the reason for it's success is it allowed HTML/CSS 'programmers' to progress to simple scripting within their existing deployment metaphor (upload via FTP, use a PHP file extension, wrap PHP in However, there's no reason that you couldn't design a similar thing in say, Ruby or Python, where people upload files with a specific extention FTP and it runs some templating language (like ERB or Pythons equivalent). You'd need some web api to allow triggering reloads of files (or reloads on every request if the server is being used for development).
PHP out of the box re-parses _every single script on every single request_, which is what you'd expect a development environment to do, but 'in production' that's what PHP has always done.
Hence were born the optcode caches (which work rather well now), like APC. But still, on every request, every file that is required has a stat performed on it (you can turn this off, though).
It's all very lowest common denominator, and the high end stuff is severely lacking and poorly documented. It's possible to have the best of both worlds (well designed language, pragmatic libraries and toolset out of the box, simple deployment AND well defined high end high traffic considerations), but PHP ain't it.
Re: These are things in PHP which make me sad
#179I'd love to see similar lists for other languages. I've been coding in MATLAB as of late, for instance, and rediscovered my hatred for the fact that you can't index the output of a function without assigning to a temporary variable. For instance, `foo(args)(:)` causes an error. You have to use `X = foo(args); X(:)` instead. That makes me just as sad as some of these PHP sadnesses.
MATLAB does get one thing right: Function arguments are always passed by value . This "referential transparency" really makes it easier to reason about functions and test them. It's the one thing I hate about SciPy. Passing by reference for performance reasons should be automatically handled by the compiler. I.e., A=sort(A) should be handled in-place without requiring a new function sort!(A).
Re: These are things in PHP which make me sad
#180Earlier quoted context omitted.
The core team has it's own priorities, and has a history of ignoring the requests of the dev community. A couple of examples: in version 5.3, they added `goto`. WTF. Who, after five major releases, decides that what a language really needs is `goto`. In the same release, they decided to finally add namespaces. But, despite the tired claim that PHP takes cues from C/C++/Java, they did not reuse :: (aka paamayim nekudo…
None of these languages except for PHP have their own string concatenation operator. They overload + for that purpose. They're also all strong typed languages while PHP is weakly typed. Overloading + for string concatenation in a weakly typed language is a recipe for disaster (see JavaScript). > Who, after five major releases, decides that what a language really needs is `goto`. It makes it a much easier compilation…
Looking at your responses all over this post, there is a big disconnect. Other people -- who probably use and enjoy other languages -- raise issues with PHP that point at poor design. Then you respond with a rationale for why the well-designed thing couldn't be done. (Or, why the poorly-designed thing was done.)
But all designs have rationales. The point is that the people who make design decisions for PHP choose poorly. Even if you give us the rationale, that doesn't make it a good decision in retrospect.
Also, could you explain this statement please:
> It makes it a much easier compilation target.
Do you mean that other languages can be compiled to PHP more easily? Because I have never heard this rationalization before.