We are stored procedure-centric. An ORM wouldn't help us. What Moose brings is an ability to bring the sort of rich type constraints we are used to doing in-db into the application level.
This is pretty neat. I'm always in favor of multiple levels of data validation and your use of Moose is good in this sense. Check out Data::Manager as well (or Data::Verifier if you just want the validation goodness), it uses Moose's type constraint system to validate your data.
I have lots of cronjobs that use the Moose type system to validate data before it gets inserted into either a MySQL row or an ElasticSearch document.
It's a really nice method and has caught a lot of errors in the data those jobs are slurping up before they've impacted production.
It also allows you to do very complex type checking that you wouldn't be able to do in the native type systems of most languages (e.g. with MooseX::Types::Structured), like checking not only whether something is a hash, but it can only have these keys, and each of those keys have to match some constraint.
Obviously you can write custom code to do all that, but offloading it to the type system is so much nicer, and makes it trivial to share those checks between different modules.
It also makes it easy to selectively disable checks, e.g. if you have a large blob of data you're inserting into permanent storage in a cronjob you might like to to extensive validation of it, but you might not want to incur that validation cost on every retrieval in the system that consumes that data.
Moose is easily the biggest administrative pain in the ass of all time. Any::Moose just makes it work. If you can get away with pure-perl Mouse, it's okay -- but once you dive into Moose... I hope you handle your own hosting.
Typically LedgerSMB is hosted by people who know what they are doing regarding the software, or it is self-hosted on-premises by the customer. I know of a few hosting providers. One charges $20/month for the service.
We are running on PostgreSQL which removes most of the options for $3/month hosting anyway.
But we already have dependencies that require Moose and therefore there isn't much point in avoiding it.
I have never ran into any of the issues that you had with Moose. I've been using Moose since 2007 and its always been seamless to install, manage and use.
bringing moose into the core of perl would be a major undertaking but would be an absolutely fantastic major upgrade for the language...it would address my major gripe with moose - the deplorable performance (yes i know about mouse and mo etc)
Moose is nice and full-featured, but slow. So Mouse was created to be similar to Moose, except a bit more limited and faster. However Mouse still has a ton of features and complexity, so Moo was written to be just the most used 60% of Moose, implemented as simply as possible.
Different Perl libraries have chosen to use different ones. So in a large Perl project that uses a bunch of standard libraries you can easily wind up pulling in all three. Thus the common desire to produce something lightweight and fast has created bloat and slowness.
11 comments
[ 3.5 ms ] story [ 18.2 ms ] threadIt's a really nice method and has caught a lot of errors in the data those jobs are slurping up before they've impacted production.
It also allows you to do very complex type checking that you wouldn't be able to do in the native type systems of most languages (e.g. with MooseX::Types::Structured), like checking not only whether something is a hash, but it can only have these keys, and each of those keys have to match some constraint.
Obviously you can write custom code to do all that, but offloading it to the type system is so much nicer, and makes it trivial to share those checks between different modules.
It also makes it easy to selectively disable checks, e.g. if you have a large blob of data you're inserting into permanent storage in a cronjob you might like to to extensive validation of it, but you might not want to incur that validation cost on every retrieval in the system that consumes that data.
We are running on PostgreSQL which removes most of the options for $3/month hosting anyway.
But we already have dependencies that require Moose and therefore there isn't much point in avoiding it.
To load Moose on a vanilla perl only takes a couple of minutes and only uses 22 other modules: http://news.ycombinator.com/item?id=4042637
Different Perl libraries have chosen to use different ones. So in a large Perl project that uses a bunch of standard libraries you can easily wind up pulling in all three. Thus the common desire to produce something lightweight and fast has created bloat and slowness.