PHP Object Oriented Programming Reinvented | Hacker News Reader

PHP Object Oriented Programming Reinvented

dhotson.tumblr.com

33 pointsdhotson33 comments

The Common Lisp Object System is based on similar principles. "The Art of the Metaobject Protocol" by Gregor Kiczales, Jim des Rivieres, and Daniel G. Bobrow describes its architecture, along with protocol used to extend it. Despite it did not make it into ANSI spec, it is a de facto standard and is widely implemented.

This may come off in a pejorative way but thats definitely not my intention...

Is the intention here to make PHP more Ruby like? If so why?

I'm not the author, but it could be. As an 11 year PHP programmer, why not? Ruby certainly has some nice language features, is well respected, and has gained a lot of ground recently. Why not borrow some ideas?

Yeah i agree, which was one of the reasons for asking. I'm a PHP guy myself, i've not taken the time to properly learn Ruby but i am aware of some of its features and i remember thinking at the time "thats very cool, i wish PHP did that", so yeah, totally with you.

Upmodded for asking an interesting question, namely "why?"

Perhaps there is some sort of ideal that Ruby's author Matz and the author are both striving for. If Ruby is closer to the ideal than PHP, an observer who examines the two languages and this work may wonder if the intention is to make PHP programming more like Ruby programming, where is actuality the author is seeking the ideal.

This trick of perspective probably explains why so many people seem to reinvent Lisp over the years. They aren't trying to turn their languages into Lisp, they're seeking what Lisp's authors have sought over the years but haven't found another path towards the ideal.

As to why... PHP and Javascript are both very interesting because they are so widely deployed by default and have a very large "market penetration" amongst programmers.

Once you get past the "uncool factor," reaching PHP programmers is probably one of the highest value activities a toolsmith can pursue.

JM2C.

Thanks for taking a look Reg.

Would you mind if I ran an idea past you?

The other idea I'm toying with is something similar, but having immutable classes. So basically every time you add a new method, instead of modifying the class you would return a brand new class.

Crazy? :-)

Running through that in my head, that's basically equivalent to subclassing. At least, I can't find a difference. (In fact if you do it the naive way you'll end up with something less functional than subclassing for no good reason, so you might as well just treat it as a subclass.) It also blocks monkey patching the original class, which I observe neutrally.

Not at all. Thanks for taking a look. :-)

Yep, the intention was to implement classes in a more dynamic and hackable way. Ruby was certainly an inspiration, but I'm not really trying to copy it if that's what you mean.

Ruby is pretty good in this regard, except that classes are global. This means that any change you make to a class is permanent (it's not scoped).

It's an interesting idea but it adds a lot of indirection and extra code for every method call. I'd like to see some benchmarks, but my guess is that this technique slows things down a lot.

I had the exact same thought. PHP is already dog slow... that's one of it's trade offs. An extra layer of indirection would kill it.

Also, you are losing a few important feature of PHP by doing this:

- Type hinted arguments (http://www.php.net/manual/en/language.oop5.typehinting.php)

- Static method calls

- Autoloading

And there are a bunch of things that would become nightmarish to manage. For example, object serialization or cloning.

I'm sure the speed is awful. But that's not the point.

Also, type hinting isn't all it's cracked up to be in PHP. In my opinion, type hints don't fit well in a dynamic language like PHP. The main problem I have is that you can't pass a decorator object to type hinted methods. Also, it makes it harder to pass mock objects for test cases.

Static method calls are possible, you can just add and call methods on the class object.

Autoloading probably isn't too hard to figure out.

You make a good point about serialisation. Closures can't be serialised. To be fair though, you can't do it in Javascript either.

> I'm sure the speed is awful. But that's not the point.

Fair enough. I can appreciate that you have done an interesting bit of hackery here. Along that vein, you might consider adding support for uniform access. With this, methods without arguments can be called as properties, and properties could be exposed as read/write or read-only.

> Also, type hinting isn't all it's cracked up to be in PHP.

This is a matter of taste, but I completely disagree. In my opinion, type hinting is one of the redeeming qualities of the language. It means that PHP is taking care of the sanity checks for you. Of course, I'm partial to strongly typed languages.

> The main problem I have is that you can't pass a decorator object to type hinted methods.

Polymorphism allows you to do this. In the context of decorators, that usually means defining an interface.

> Polymorphism allows you to do this. In the context of decorators, that usually means defining an interface.

This doesn't work if you have a generic decorator class. You can't really make it implement all the interfaces you potentially want to use.

It's the same problem with mock objects in test cases. You can't pass them because the type check prevents it, even though in practice everything would work just fine.

Autoloading will be harder than you think, but if you can that working then serialization will partially work.

Reading on my mobile so its hard to tell but it looks a little like prototype based OO. The dynamic languages all sort of lend themselves to build your own OO hacks like this.

See Joose, Moose, and Cappucino for other examples.

You'd think after five years in php I would have picked up on that nifty method to chain methods together.

(referring to :

function Obj($methods=array()) )

Awesome hack dude.

Thanks. :-)

Although, usually I go for a static create() method instead of a function.

Oh man, I really wish they'd make constructors chainable. :-(

I like it. I wasn't aware you could have function names with the same name as a keyword.

Ninja edit: appears you can't, it has to be an undefined method caught with __call(). Neat.

At first glance I was thinking this was prototypal, but upon a second look, it doesn't seem to be. It does however, seem like this approach would make it easy to get prototypal inheritance, no?

As someone who has been coding PHP for over 5 years, I don't see any obvious benefit of doing OOP this way in PHP except for making your code look clever. Any explanation would be appreciated.

Steve McConnell would like a word concerning non-idiomatic programming.

I have no objection to Mr. McConnell joining us, having his say, and explaining why his maxims are a greater good in the domain of PHP programming. Until then, perhaps you may want to make a point that you feel doesn't need an Argument from Authority?

http://en.wikipedia.org/wiki/Argument_from_authority

It was kind of a joke.

Excellent! have another upmod for catching me out as a cranky old man :-)

Hey it happens to the best of us.

Intersting idea, but what does this have that ruby or javascript doesn't?

I don't think that's the point. He didn't create a new language, he is working at bringing that style of programming to PHP development.

Yup, I could have implemented this in pretty much any language with closures and some sort of __call / method_missing magic.

It's mostly just a fun hack to experiment with a different OO style. By no means would I recommend using it in any way.

Although, that said. A little language on top of this would be kind of neat...

Component based object oriented-ish ala Ruby?

ok, someone has to point that out: POOP'R?

He did, in the second paragraph of his post.

I kind of hope it catches on, just so I can tell people with a straight face that I'm familiar with "Pee Aytch Pooper".

I did mention that it was kind of unfortunate.. ;-)

Unfortunate? Keep working on it, man. I want to say "PHPooper" during an interview some day.

Reply on news.ycombinator.com