Show HN: PHP does Meta Programming too

https://gist.github.com/1180947

by yuri41 • 15 years ago

45 24 15 years ago

gist.github.com

Oh god, no! If they rather fixed the eye-stinging bugs instead of creating other hundreds of them.

akie• 15 years ago

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.

apgwoz3• 15 years ago

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.

rmccue• 15 years ago

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.

okal• 15 years ago

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.

pharno• 15 years ago

nice I think theres room for a small improvement. change $this->{$property} to $this->properties[$property]

see my fork.

Jach2• 15 years ago

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.])

philjackson• 15 years ago

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?

Jach2• 15 years ago

Yeah, I was thinking of Moose. Since I said CLOS I should have said Moose to be consistent!

dmoney• 15 years ago

Thanks! Didn't know about traits [ http://php.net/manual/en/language.oop5.traits.php ].

dave1010uk• 15 years ago

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

damncabbage• 15 years ago

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.

larve• 15 years ago

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.

troels3• 15 years ago

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.

mardiros• 15 years ago

This is awful.

mechanical_fish2• 15 years ago

Is 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?

nolok3• 15 years ago

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.

mechanical_fish2• 15 years ago

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.

Show HN: PHP does Meta Programming too

Related Stories