On Thursday, August 24, Aaron Trevena wrote:
> > Can the subroutine just be removed?
>
> I could remove the entry from mk_classdata, as it's pretty much
> redundant (it provides get/set_view_object, which aren't used), it
> might actually be worth renaming the mk_classdata entry to
> _view_object to make it clearer and stop the warnings.
Hmm, okay. I thought it was the other way around. mk_classdata
creates a symbol table entry for view_object at run time, overwriting
the one that the subroutine declaration created at compile time. (Also,
removing the sub didn't seem to break anything, whereas removing the
mk_classdata entry did.)
Seems to me that all the current calls to view_object (e.g.
$self->view_object->process, $self->view_object->error) are using
mk_classdata's subroutine. If they were using the other one, they'd
produce an error, since no hashref is sent as a first parameter (which
there would need to be for the "if $r->{parent}" to not die).
I don't see anything in Class::Data::Inheritable about creating
subs named get_/set_whatever.
thanks
Brian
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Maypole-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maypole-devel
