Page 1 of 2

Protoype OOP in PHP

Posted: Sun Dec 06, 2009 4:58 pm
by VladSun
I miss prototype based OOP in PHP so much!
I have some hopes that "closures" will be close enough to it, but obviously they are not :(

Thoughts?

PS: Every time I hear it's a "cross-cutting concern" I regret that PHP OOP is class based :( ... or maybe I an wrong about it?

Re: Protoype OOP in PHP

Posted: Sun Dec 06, 2009 8:26 pm
by alex.barylski
PS: Every time I hear it's a "cross-cutting concern" I regret that PHP OOP is class based ... or maybe I an wrong about it?
I think both have their pros and cons, personally I prefer class based OOP, but that could easily change in the near future. I'm a huge fan of jQuery so you never know. :)

In anycase, in regards to cross-cutting concerns, these can be circumvented using class-based implementations, but you need a extensible architecture similar to Drupal/WordPress, to inject hooks (observers) at certain point of execution. Thus allowing you to add code that would be considered a cross-cutting conern, such as a logging class, etc.

Drupal, interestingly enough, doesn't use OOP, and the difficultly in implementing a hook system is one of their most common arguments for not supporting true OOP using classes. Joomla does it, but they implement objects as being observable, which is not quite as flexible as hooks, but in the end accomplish the same result, circumventing cross-cutting concerns while supporting a truly pluggable infrastructure.

It will be interesting to see how PHP culture adopts closures and what kind of neat solutions they solve, like how jQuery is brilliant, I wonder if PHP will have something similar in dealing with frameworks, etc.

Cheers,
Alex

Re: Protoype OOP in PHP

Posted: Mon Dec 07, 2009 11:29 am
by Christopher
I think you desire for prototype based OO is probably based more on how you want to solve the problem rather than whether you can. Dealing with cross-cutting concerns is more difficult in traditional class based languages because of the protections built into the languages to prevent doing such things lightly. I think modern scripting languages have changed our ideas of the kinds of protections languages should provide.

Maybe when Traits come they will provide a little relief, but probably not: http://wiki.php.net/rfc/traits

Re: Protoype OOP in PHP

Posted: Mon Dec 07, 2009 9:05 pm
by alex.barylski
I think modern scripting languages have changed our ideas of the kinds of protections languages should provide.
For me, PHP and JS have been huge. Static programming techniques, while neat in their own right, have major disadvantages which impede development of interesting solutions.

About the only thing I miss about static programming is that there are a lot of static analysis tools out there but few to none for PHP, because the difficulty in implementing such a thing. Dynamic analysis is a challenge which has always intrigued me.

Cheers,
Alex

Re: Protoype OOP in PHP

Posted: Tue Dec 08, 2009 4:03 am
by VladSun
arborint wrote:I think you desire for prototype based OO is probably based more on how you want to solve the problem rather than whether you can. Dealing with cross-cutting concerns is more difficult in traditional class based languages because of the protections built into the languages to prevent doing such things lightly. I think modern scripting languages have changed our ideas of the kinds of protections languages should provide.

Maybe when Traits come they will provide a little relief, but probably not: http://wiki.php.net/rfc/traits
My PHP desires: http://www.extjs.com/deploy/dev/docs/?class=Function :)

Re: Protoype OOP in PHP

Posted: Fri Dec 11, 2009 3:42 pm
by alex.barylski
The more I play with that library and look at it's design, I am really blown away by it's brilliance. I was impressed with jQuery but extJS takes the cake. I love how they have adapters to let you use any underlying framework (ie: jQuery).

Re: Protoype OOP in PHP

Posted: Fri Dec 11, 2009 5:50 pm
by josh
I see the use case for all this features, but if code were written properly it would not be needed. For instance prototyping in methods to the Window object would not be needed if the scripting languages consistently supported interfaces & adapters for extending them

Re: Protoype OOP in PHP

Posted: Sat Dec 12, 2009 5:18 pm
by Jenk
Prototyping has its place, but I'm always wary of it, as it can be a dangerous slope to slide down to use it just to avoid needing to implement something "properly".

There are ways to pseudo implement prototyping already within PHP. An example Prototype object would be:

Code: Select all

class ValueHolder
{
  public values = array();
  public __set($name, $value)
  {
    $this->values[$name] = $value;
  }
  public __get($name)
  {
    if (isset($this->values[$name])) return $this->values[$name];
    return null;
  }
}
That combined with create_function() etc could well give you a prototype object, only without the short-hand syntax.

Re: Protoype OOP in PHP

Posted: Sat Dec 12, 2009 8:36 pm
by josh
Yeah if you have the need to add a collection of methods to every object in the application, you should put that collection of methods on an first class object of it's own, and use dependency injection, IMO which solves the same problem. Prototyping is extremely useful though, for working with code out of your control.

And I might add a fluent interface around Jenk's code could easily be made, with OOP

Code: Select all

$MyModel->create()->callBack( 'callbackName' )->will( $this->execute(array($this=>'method' )) );
(or something). Not exactly short hand but I'm sure it could be massaged into a "prototype" framework. Instead of create_function() this would assume you wanted to use the 'command' design pattern for your callbacks, the command would be used ala the strategy pattern whenever the magic callback method is invoked.

But it defeats the purpose if the code is outside of your control, which is the only use case I see for it. Meh.

Re: Protoype OOP in PHP

Posted: Sun Dec 13, 2009 6:37 am
by VladSun
josh wrote:Yeah if you have the need to add a collection of methods to every object in the application, you should put that collection of methods on an first class object of it's own, and use dependency injection, IMO which solves the same problem.
Yes, but prototyping will achieve this in far more easier and intuitive way.
josh wrote:Prototyping is extremely useful though, for working with code out of your control.
Exactly!
josh wrote:And I might add a fluent interface around Jenk's code could easily be made, with OOP

Code: Select all

$MyModel->create()->callBack( 'callbackName' )->will( $this->execute(array($this=>'method' )) );
How about having this:

Code: Select all

 
class Model
{
...
public function __construct()
{
    foreach (ACL::getInstance()->getRules() as $rule)
        // createInterceptor(callback, arguments)
        $this->{$rule->method}->createInterceptor(array('check', ACL::getInstance()), array($MyModel, $rule->method));
    $MyModel->save->createInterceptor('log', $Logger);
    ...
}
:)
Probably, you'll say again it can be solved with other, "more proper" OOP patterns, but again, I feel like it's the most intuitive way to do it.

Re: Protoype OOP in PHP

Posted: Sun Dec 13, 2009 6:50 am
by VladSun
Jenk wrote:That combined with create_function() etc could well give you a prototype object, only without the short-hand syntax.
IMHO, create_function() is an awful way to do this (passing code as a string!) - closures are better than that, but even they can not be executed as object methods.

Re: Protoype OOP in PHP

Posted: Sun Dec 13, 2009 8:31 am
by Jenk
Completely forgot anonymous functions had been added to php. :)

Re: Protoype OOP in PHP

Posted: Sun Dec 13, 2009 4:00 pm
by josh
VladSun wrote:Yes, but prototyping will achieve this in far more easier and intuitive way.
Well that's subjective, my opinion is that you're just cheating your way out of decomposing your design, and as a side effect creating god objects at runtime

Re: Protoype OOP in PHP

Posted: Sun Dec 13, 2009 5:30 pm
by VladSun
josh wrote:
VladSun wrote:Yes, but prototyping will achieve this in far more easier and intuitive way.
Well that's subjective, my opinion is that you're just cheating your way out of decomposing your design, and as a side effect creating god objects at runtime
I've had such cases - I needed a toHash() method for every single object in my JS application. So, I extended the base object prototype.
Does it mean I've created a "god" object - don't think so.

And as I mentioned, I miss prototyping when it comes to cross cutting concerns - i.e. attaching (at run time) interceptors/delegates to the very base class methods - effectively attaching them to every instance of this class and inherited ones.
Certainly, I could do it by using an event driven design, but it's harder and works for class instantiations.

Re: Protoype OOP in PHP

Posted: Sun Dec 13, 2009 7:09 pm
by josh
VladSun wrote: I've had such cases - I needed a toHash() method for every single object in my JS application. So, I extended the base object prototype.
Does it mean I've created a "god" object - don't think so.
Every object in the entire application :dubious: means your application is not layered and you have no differentiation between value/ entity objects.