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
Moderator: General Moderators
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.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?
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.I think modern scripting languages have changed our ideas of the kinds of protections languages should provide.
My PHP desires: http://www.extjs.com/deploy/dev/docs/?class=Functionarborint 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
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;
}
}Code: Select all
$MyModel->create()->callBack( 'callbackName' )->will( $this->execute(array($this=>'method' )) );Yes, but prototyping will achieve this in far more easier and intuitive way.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.
Exactly!josh wrote:Prototyping is extremely useful though, for working with code out of your control.
How about having this: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' )) );
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);
...
}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.Jenk wrote:That combined with create_function() etc could well give you a prototype object, only without the short-hand syntax.
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 runtimeVladSun wrote:Yes, but prototyping will achieve this in far more easier and intuitive way.
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.josh wrote: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 runtimeVladSun wrote:Yes, but prototyping will achieve this in far more easier and intuitive way.
Every object in the entire applicationVladSun 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.