As was pointed out, you need to take care of possibility someone
subclass will implement stringification overload. A solution was
proposed - alternatively, you can document that it's forbidden
for a subclass to overload stringification if you don't want
to pay the penalty. I think this isn't a major issue; overloading
is used, but most objects don't.
You have to write a DESTROY method. You can't say that you can
live with the memory leak - Perl does not garantee that if you
create a reference, let it go out of scope, and then create a
new reference, the new one will not have the same address as
the first one.
Serialization might be a bit harder in some cases. But calling
Serialize or Date::Dumper on an object won't work in general
anyway. An object might have a reference to something, and
a general serialization function cannot know whether the
reference needs to be shared with something else.
You can't use the standard Class::MethodMaker. But that doesn't
mean you can't have a module giving you the same functionality.
I've written a proof of concept Class::MethodMaker::InsideOut
(not released) giving the same functionality as Class::MethodMaker
for Inside Out objects. It'll can even do the DESTROY function
and the declaration of hashes. It's using a source filter.
Alternatively, you could use our to declare the
attribute hashes, and write a module with the same functionality
as Class::MethodMaker.
If you have a large class, you may want to split it over more than
one file. If your attribute hashes are lexical, this will not work.
Again, you could use a source filter to merge the files, or
declare the attribute hashes with our.
Just in case you are saying that making the attribute hashes
package variables makes that someone else can access your attributes,
that's ok. I'm not advocating my technique such that you cannot
get to the attributes, I want to prevent accidents.
After all: "It would prefer that you stayed out of its living room
because you weren't invited, not because it has a shotgun."