

Show HN: PHP does Meta Programming too - yuri41
https://gist.github.com/1180947

======
mechanical_fish
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?

~~~
nolok
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_fish
_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.

~~~
nolok
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.

------
damncabbage
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
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.

~~~
troels
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.

~~~
nolok
Closures came with 5.3

~~~
troels
Sorry, you're quite right.

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

~~~
dave1010uk
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>

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

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

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

see my fork.

------
mardiros
This is awful.

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

~~~
akie
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.

~~~
apgwoz
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.

~~~
troels
That was fixed pretty fast though (Notwithstanding that it shouldn't have
happened in the first place, but hey)

~~~
apgwoz
Sure, but when a bug like that occurs it gets "mainstream" press and PHP
haters everywhere add it as part of the book of "Ugh, PHP Y U So Horrible?"

~~~
apgwoz
downvoters: If you disagree, at least tell me why...

