Show HN: PHP does Meta Programming too(gist.github.com)
gist.github.com
Show HN: PHP does Meta Programming too
https://gist.github.com/1180947
7 comments
PHP 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.
NOTHING 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.
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.
Then I don't understand why you complain about traits, since they are actually reducing the amount of support and code replication everywhere (unless the code using traits is a piece of crap to start with, but then you probably shouldn't depend on that).
Not adding painfully needed features such as traits and closures (which got similar comments before that) just because it would make life harder for those who don't enjoy/want to code in php anymore would in my opinion be a bad thing.
Not adding painfully needed features such as traits and closures (which got similar comments before that) just because it would make life harder for those who don't enjoy/want to code in php anymore would in my opinion be a bad thing.
I 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 (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.
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 (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.
coming 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.
good fun indeed, you still have to be aware of a lot of php quirks though to make your code secure.
Closures 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.
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.
Thanks! Didn't know about traits [ http://php.net/manual/en/language.oop5.traits.php ].
I'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
I 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; I'm more or less in agreement with jerf.])
I'm a perl advocate, but isn't saying it has a "proper" object system pushing it a bit? Perhaps you're talking about Moose?
Yeah, I was thinking of Moose. Since I said CLOS I should have said Moose to be consistent!
nice
I think theres room for a small improvement.
change $this->{$property} to $this->properties[$property]
see my fork.
see my fork.
This is awful.
Oh god, no! If they rather fixed the eye-stinging bugs instead of creating other hundreds of them.
I 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.
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.
I think he's referring to bugs such as breaking crypt() when using an md5 hash as a salt, and other things of that nature.
That was fixed pretty fast though (Notwithstanding that it shouldn't have happened in the first place, but hey)
There'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.
It is fairly annoying to have any differences, but it's fairly easy to remember them.
Could 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.
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?