|Think about Loose Coupling|
Re: Lets talk Mooseby stvn (Monsignor)
|on Jun 28, 2006 at 22:06 UTC||Need Help??|
Let me start out by saying the documentation for Moose (and it's parent module Class::MOP) is sorely lacking and that this will change. However, given the amount of $work I currently have on my plate, this is likely to change fairly slowly.
The reason why you have not heard much about it here is because I am purposefully not screaming about it from the mountaintop. It is currently only really ready for the "Early Adopter" crowd. We need adventurous people to build make cool stuff in it to work out all the deep ugly corner case bugs and such.
Now, to answer your questions:
Has anyone done anything *really* cool with Moose? ... Has anyone done anything with Moose worth mentioning?
nothingmuch (who is also a core Moose/Class::MOP developer right now) has written Class::Workflow in it. He is also working on a drop-in Catalyst dispatcher replacement built on Moose, but this is not released yet.
It is also being used/experimented-with by chansen and marcus (two of the core Catalyst developers), as well as mst, the author of DBIx::Class. Also sri's new web framework Mojo was (last time I checked) using Moose as well.
On the Perl 6/Pugs front, fglock recently added Moose support to v6-pugs (although I am not sure that has yet to be released). The current plan (which I will be discussing in more detail with audreyt during this weeks hackathon) is to use Moose as the meta-level for the Perl 6 on Perl 5 runtime.
I'm not all that fond of the complexity of what should be simple tasks, like adding prefixes to the writer/reader, 'set_', and 'get_', or making those prefixes defaults.
The simplest way to do this is to explicity set the reader and writer's for an attribute. The code would look like this:
There currently is no way to set this as the default behavior. If you would like that, please come to #moose on irc.perl.org and we can talk it out. However, keep in mind that this cannot be set as default on a Moose-wide basis because it would interfere with other Moose based modules, and what they expect. But this is not an unsolvable issue, I simply need a good solid use case, and to work out the API.
And, I generally think lowly of classes that reference users with such trivial needs to the source of the parent class.
Again, I apologize for the poor docs. Patches are always welcome :)
Is there any class-builder preferred over Moose, by anyone?
Of course I am biased, so I won't answer this directly. However, please keep in mind that Moose is more than a "class builder", it is a full object system for Perl. There is much work done "under the hood" to make Moose possible, and to make it play well with non-Moose classes. The only other module which has such ambitious (aka - completely insane) goals is Class::Meta.
I see Moose fitting in pretty well to model a relationship between columns => tables => schemas => dbs
Yes, I have had several conversations this week at YAPC::NA with people about exactly that. The level of meta-information stored by Moose could be very effectively used by an ORM.
Would you use Moose's type validation components? Or is there a better way to validate SQL datatypes, without really calling the DB?
This is actually something mst (of DBIx::Class fame) has been experimenting with, and again something I have been discussing with people here at YAPC. Currently the big problem is that Moose's type validation features store the actual validation in a code block. This makes it difficult to introspect in a way which can be translated to SQL (unless of course you are a serious B hacker that is). But since Moose's type validations are actually stored as meta-objects themselves, it should be very possible to fiddle with this and get what you are looking for.
So, I hope this has answered some of your questions. Feel free to ask on #moose (on irc.perl.org), I will try to be there the rest of this week (connectivity was a bit spotty at YAPC, so i was not around). Or feel free to email me at the address listed on my CPAN page. As I have said, we are always looking for a few brave souls to help us work out all the edge cases and bugs.