6 ms·
Show HN: PHP does Meta Programming too
- kachnuv_ocasek 15y agoOh god, no! If they rather fixed the eye-stinging bugs instead of creating other hundreds of them.
- akie 15y agoI work with PHP daily and do not know of what you speak. Haters be hatin', but your 'eye-stinging bugs' are unknown to me. Care to provide some examples? You are probably referring to the mountains of crappy PHP code? About the inconsistent order of 'haystack' and 'needle', or the lack of a common policy on whether or not to use a underscore as separator? Those are valid complaints, but no argument against improvement of the language. On the contrary, I would say.
- apgwoz 15y agoI think he's referring to bugs such as breaking crypt() when using an md5 hash as a salt, and other things of that nature.
- troels 15y agoThat was fixed pretty fast though (Notwithstanding that it shouldn't have happened in the first place, but hey)
- rmccue 15y agoThere's a fairly consistent order of haystack/needle, but it depends on what the function does (i.e. string functions vs. array functions). It is fairly annoying to have any differences, but it's fairly easy to remember them.
- okal 15y agoCould just be me, but it seems like there's a decided bias against PHP on a lot of HN threads. As someone who uses PHP on a regular basis, I'd love it if you could point out some of these "eye stinging bugs". I experiment a LOT with other languages and I don't find anything lacking in PHP that I need in a scripting language. I've never been unable to accomplish anything that I needed to in it, and I personally don't recall ever having to resort to unsightly hacks. All this whining is getting rather old. PHP is not Clojure, Ruby, Node or [insert your favorite language/tech here], and guess what? Some of us like that, a lot.
- pharno 15y agonice I think theres room for a small improvement. change $this->{$property} to $this->properties[$property] see my fork.
- Jach 15y agoI heard about this recently too. All to avoid the design error of not allowing multiple inheritance, along with other design errors of not having a proper OOP system such as Python's, Ruby's, Perl's, or CLOS. I work with PHP pretty frequently and I like the language for what it does well, I might even use Traits when 5.4 is the new 5.2, I just can't get excited about features other languages have had for a long time. (I guess I've become a Lisp snob or something even though I don't use Lisp all that often. [ see http://news.ycombinator.com/item?id=941740 http://news.ycombinator.com/item?id=941740; I'm more or less in agreement with jerf.])
- philjackson 15y agoI'm a perl advocate, but isn't saying it has a "proper" object system pushing it a bit? Perhaps you're talking about Moose?
- Jach 15y agoYeah, I was thinking of Moose. Since I said CLOS I should have said Moose to be consistent!
- dmoney 15y agoThanks! Didn't know about traits [ http://php.net/manual/en/language.oop5.traits.php http://php.net/manual/en/language.oop5.traits.php ].
- dave1010uk 15y agoI've started collecting some useful methods from classes and am turning them into traits. You can see the work-in-progress here: https://github.com/dave1010/php-traits https://github.com/dave1010/php-traits
- damncabbage 15y agoI have one foot in each of the PHP and Ruby camps. As a bit of an exercise I went through and did the equivalent in Ruby (implement a class, test adding properties and methods) just to see how it'd look: https://gist.github.com/1183334 https://gist.github.com/1183334 (Slimmed down versions of both came to 118 and 50 lines for PHP and Ruby respectively.) I'm happy Traits are coming to PHP, but given I haven't yet been able to use any PHP 5.3 features in any production environment outside of hobby projects, I'm awfully glum about the prospect of being able to make use of them any time in the next couple of years.
- larve 15y agocoming from a lisp background, and now working on a 'mid-sized' php CMS, i've been pretty happy with the reflection and other features (dunno if they are 5.3 or not) like closures to build something which has around methods, reflectioning on the docstrings to generate a REST api, etc... good fun indeed, you still have to be aware of a lot of php quirks though to make your code secure.
- troels 15y agoClosures are new in 5.4, but the reflection api has been there since 5. Indeed, PHP may not be pretty, but it's really good at hacking stuff together that just works. A lot like shell scripting, although much more maintainable. My biggest beef with PHP is that there is such a chasm between the procedural style at the object oriented one. This is mostly caused by PHP adopting a static class model (a really odd choice for an otherwise highly dynamic language). On the plus side, this tends to cause fewer surprises than you see in languages with a more dynamic object model.
- mardiros 15y agoThis is awful.
- mechanical_fish 15y agoIs it too late to explain to the PHP designers that PHP is a huge success, and that much of the reason for its success is that, for all its faults, it is not over-designed? I guess the Java envy is strong. But why would I want to read and write ersatz Java, or ersatz Ruby, when I could use the real thing?
- nolok 15y agoPHP is neither ersatz Java nor ersatz Ruby, and traits are clearly not in "over design" territory. I can understand people not liking the language but then why do you keep coming back complaining that they add user-requested features to it ... You complain that it damage PHP's simplicity but the truth is that if you don't want to use it, don't use it. NOTHING is forcing you to use it, it uses its own keywords so it won't confuse you or change existing code ... And if someone somewhere wants to use it to do meta programming, I don't see how that affects anyone else's approach to php.
- mechanical_fish 15y agoNOTHING is forcing you to use it This is the perennial argument of the feature addict, but it isn't really true. I suppose you can ignore core language features if you never read or fix any code but your own. But in a few years this new stuff is likely to start cropping up in the source code of Drupal modules and Wordpress themes and the PHP frameworks, and if that happens there will be little choice but to deal with it. The bigger problem is PHP contributor resources. When you add a core feature, that feature needs to be supported forever. The time you spend supporting it is time you could have spent fixing other things. Worse, the effect is nonlinear: Each new feature potentially interacts with all existing features, increasing your surface area for bugs. In extreme cases, you approach an event horizon where you can no longer ship anything. The painful thing about the latter effect is that it happens even if the new feature almost never gets used. One might end up doing 20% more QA and maintenance to support 0.1% of one's customers. You are absolutely right in one sense: If one simply abandons PHP altogether one need never deal with it again. The thought has occurred to me. Pity about the hundreds of thousands of existing customers, though.