Syntactic Confectionery Delight | |
PerlMonks |
Re: Better Inside-Out Objects :)by xdg (Monsignor) |
on Oct 06, 2006 at 17:18 UTC ( [id://576716]=note: print w/replies, xml ) | Need Help?? |
You don't seem to really want "inside-out" objects -- you seem to want encapsulated objects. Inside-out is just one way of doing that and it seems like you're going out of your way to try to make it act like something else. A couple quick observations:
I'll let you know if more things occur to me later. Update The more I think about it, the more this just seems like a way of disguising an accessor call by way of overloading. And there's no reason the trick requires inside-out objects. Here's a plain-old blessed hash version -- and it still gives you package-specific hash values that don't collide: SmartHash.pm
Foo.pm
Bar.pm
testbar.t
prove -v testbar.t
I guess I'm not clear on what you find so difficult about inside-out objects (assuming a sane inside-out class generator to handle destruction, serialization, threads, etc.). Is "$foo{ id $self }" so much more difficult than "$self->{foo}"? Or even "$self->foo()"? What are you trying to optimize for? The hash-based interface does avoid having to pre-declare any properties -- you can just say "$self->{baz}" and the "baz" property springs into existence. That comes at the cost of the typo checking. I can also see a use for it if you're trying to upgrade legacy code. You can just drop "use base 'Encapsulate'" into your object modules and they should continue working like normal without having to edit anything else there, but everything else external that accesses objects will break. But just as is, this feels close to an XY Problem to me. -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
In Section
Meditations
|
|