TOP POSTING IS TEH AWESUM!
But if you insist, my response is below.
On Oct 19, 2009, at 8:07 PM, Yuri Shtil wrote:
Stevan Little wrote:
Seems to me it would be better to get rid of the objects instead
of trying to make them throw exceptions when they are touched.
Do you have a real reason to leave these deleted objects around
for people to call methods on? It seems a more sensible option
would be to remove them with a C<undef $foo> or something.
- Stevan
On Oct 19, 2009, at 7:44 PM, Yuri Shtil wrote:
I designed an Moose object hierarchy that have:
- simple(scalar) attributes like name etc
- parametrized role based attributes and methods via
MooseX::Role::Parameterized
- regular Moose methods via MooseX::Method
The objects represent persistent things in the back end like but
not quite a database.
Most of the objects can be deleted from the back end via the
Remove method.
This method marks the object as deleted, however the Perl object
obviously exists until out of scope.
The problem is that it still has all properties and methods and
can be operated upon.
What would be a quick way to disable (most) of its attribute and
methods?
For example I would like to leave the name attribute alone, but
have all other attributes/methods throw an exception or set an
error when invoked.
--
Yuri
I realize that, but the objects are created via an API, I have no
control over how they are handled after Remove is called.
So I assume then that you are worried about references other people
might have for these objects?
I just foresee that people would call various methods on them and
complain about mysterious errors like not found etc.
I will be honest, this sounds like a clear case of operator error. If
you call ->Remove($obj) then call methods on $obj and then complain
that you get odd errors, seems to me the problem is obvious, and it is
not in your code :)
I would like to provide a generic error like "Object ... is stale'.
Well the simplest way to do this is to apply a role to the object
instance. However this is not the most generic solution since it would
require a "stale" version of all the possible classes, but that may or
may not be a problem I don't know your codebase.
Second way would be use the MOP to find all the methods and replace
them with "stale" versions of themselves. I would recommend you do
this on a per-object basis, something like MooseX::SingletonMethod
might be handy here.
Really though, I think it is best to not bother with this at all. The
copies of the objects that a user has access too are just that, ...
copies. If I call ->Remove( $obj ) I assume that is removing the
object from permanent storage, I may still have plans for $obj though,
and by making this object "stale" you are not allowing me that use case.
- Stevan
