I thought a top posting was a no-no :-) .
Please see my reply below.
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.
I just foresee that people would call various methods on them and
complain about mysterious errors like not found etc.
I would like to provide a generic error like "Object ... is stale'.
--
Yuri
