proxies

[mindplay.dk]

Are proxies strictly necessary?

They cause trouble for me already... proxies break Reflection
features, as the object you're retrieving really is of a different
class... even simple "reflection" like get_class (on which Yii relies
heavily) won't work properly.

Here's a code snippet where the "proxy" is actually injected as a
member into the model itself... of course, this requires the actual
model class to employ some simple _call magic to forward calls to the
injected "proxy"...

Not a super elegant approach. Any thoughts?

<?php

class Post_Proxy
{
public function __construct(Post $owner)
{
$this->owner = $owner;
}

public function getTags()
{
$tags = array('some','lazy','loaded','tags');
$this->owner->_setTags($tags);
return $tags;
}
}

class Post
{
private $tags;

public function _setTags($tags)
{
$this->tags = $tags;
}

public function _getTags()
{
return $this->tags;
}

public function __call($name, $params)
{
return call_user_func_array(array($this->__p, $name), $params);
}
}

$post = new Post;
$post->__p = new Post_Proxy($post);

var_dump($post->getTags());

[Alvaro Carrasco]

The problem is that you lose transparency... now your models are aware
of the proxies. Some may argue this is a valid trade-off (active
record?), but this transparency is a stated goal of outlet.

Also, code that uses get_class to do meaningful work is breaking
polymorphism. A method should happily accept a sub-class of its
expected input (Liskov substitution principle).

Alvaro

> --
> You received this message because you are subscribed to the Google Groups "Outlet ORM" group.
> To post to this group, send email to outle...@googlegroups.com.
> To unsubscribe from this group, send email to outlet-orm+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/outlet-orm?hl=en.
>
>

[mindplay.dk]

I understand your first concern, and I agree - the models should not
be aware of their proxies.

In the case of Reflection, an extremely useful tool that simplify many
programming tasks considerably, it does break polymorphism by
principle - if you're going to use Reflection, there is no way around
that. But usually, when applied, that's a calculated trade-off. If
you're going to use Reflection, there's no way around that.

Since get_class() and Reflection are fairly commonly used in PHP,
especially in modern frameworks, my objective here is, if it's
possible (and practical), why don't we try to find a way around
breaking normal PHP behavior? :-)

So here's another code sample:

<?php

class Proxy
{
private $entity;

public function __construct($entity)
{
$this->entity = $entity;
}

public function getName()
{
return $this->entity->name;
}
}

class ProxyManager
{
private static $proxies=array();

public static function getProxy($entity)
{
$id = spl_object_hash($entity);

if (!isset(self::$proxies[$id]))
self::$proxies[$id] = new Proxy($entity);

return self::$proxies[$id];
}
}

class User
{
public $name;
}

$user1 = new User;
$user2 = new User;

$proxy1 = ProxyManager::getProxy($user1);
$proxy2 = ProxyManager::getProxy($user2);

$user1->name = 'Rasmus';
$user2->name = 'Alvaro';

header('Content-type: text/plain');

var_dump($proxy1->getName(), $proxy2->getName());

?>

This removes the proxy from the entity entirely - it now simply keeps
track of objects by referencing the instances at run-time.

I think this is actually cleaner than what you're doing currently?
What do you think?

[mindplay.dk]

This wouldn't work at all, would it? And it doesn't really change
anything at all. Not sure what I was thinking when I came up with
this.

Clearly, what's really missing here, is actual overloading. I guess
until PHP supports that, there's really no way around the proxy
pattern...

Or is there? The proxy pattern gets in the way of a number of things
I'd like to do. I gotta keep thinking about this one...