There are conflicting requirements for WebNano. On one hand I would like to build big heavy web applications based on it, and of course I would like to use Moose as the object framework for them. On the other hand I would like to give it a chance to work in the restricted environments of most shared web hosting serving CGI scripts - so heavy dependencies and XS and big startup times are out. And I would also like to make it suitable for serving huge amounts of simple Ajax requests - so it needs to be fast.
First I tried using Any::Moose and let people decide if they used Moose or Mouse. By using Mouse people could solve the startup problem and also there is some way to use Mouse without XS.
But Mouse was still huge dependency - so next I asked myself it it would be possible to subclass in Moose a non Moose base classes. That proved to be rather simple with the aptly named MooseX::NonMoose. Using it in WebNano I can build my objects in what ever way I choose and as long as I stick to the standard hash based objects I can extend the WebNano classes in my Moose based applications with no problems. Or at least it seems to be with no problems for me now - if someone knows more about disadvantages of this solution - please leave a comment.
After discovering MooseX::NonMoose I switched to use Class::XSAccessor. It small and very fast, but unfortunately it was XS based. I was thinking about the possibilities of bundling the software as a PAR package or so and using it in the restricted shared hosting environments and relying on a C compiler seemed to complicate things a lot.
Next I tried Object::Tiny, it was tiny, fast and did not use XS, there was just one but - it did not produce the attribute setters. I could live with that and it did not take much time for me to port WebNano to use Object::Tiny, but still it seemed like an extreme choice. Fortunately just browsing CPAN I discovered a fork of O::T - Object::Tiny::RW - this one is small, fast, does not use XS and does produce attribute setters. I am still a bit worry about why Adam would not add that feature to his module - given that it is such a trivial change (compare the sources of Object::Tiny::RW and Object::Tiny - its just one line changed), he must have had a good reason for that?
Saturday, August 14, 2010
Subscribe to:
Post Comments (Atom)
4 comments:
I imagine the reason he left off the attribute setters is the same reason people complain that base.pm spends so much time working on them. I don't actually know what that reason is, but I suspect they're related.
I shall write up a post to explain, might be a good change to walk through the logic of writing a ::Tiny module.
Adam writes about the general case.
I'm a lowly wormlike programmer who builds software via an accretion process not unlike mollusks manufacturing their shells.
I started with the code from Object::Tiny, added the behaviors I want and took responsibility for them. If you're writing Catalyst stuff, I would think you are up to it, especially since "it" is merely "use Object::Tiny::RW".
I didn't know about the latter, and rolled my own (less beautiful) setter code.
I added a behavior that subclasses below Object::Tiny automatically get the parent class attributes. I added some YAML serialization code.
Maybe I am ignorant of the dangers, but I just wrote in what I needed.
"Suitable for a particular application" is different than "suitable for the whole universe."
I`am re-invent weel and make my own object swiss-knife named Object::Botox (it have some performance trouble, I fix it soon), because I dont like any other accessor module.
I think ::Tiny as an optimization - it great, but I dont need it right now :)
Post a Comment