dave is asking whether we (cpan authors) would consider migrating to moose.
between moose which brings a lot of nice features, moosex extensions such as attributehelpers (which i'm being said is going core) or moosex::poe (poe integration ftw!), there is so much that moose can bring to developers!
less fuss, less coding, more fun...
of course, moose is a bit slow during startup (but not afterwards). but even if i respect adam's will not to slow down padre too much during startup, i'd be in favor of using it nevertheless for padre. after all, we can expect some speed gains if moose's adoption continues to rise.
so, at least for me, the answer to dave's question is a definitive yes! i am considering switching to moose, and i'll end up doing that when i'll have the tuits to migrate my modules.
note: i should also add that since i'm at it, i'll also switch my modules to dist::zilla, which does a fantastic job to promote lazyness :-) but that's another topic...
Subscribe to:
Post Comments (Atom)
I totally agree with you on this one. The startup of Padre with Moose wont be that noticeable when compared to fully-fledged IDEs such as Eclipse and NetBeans.
ReplyDeleteWhat about using something like App::Persistent (http://blog.jrock.us/articles/App::Persistent.pod) to load the whole application once at login as a server?
ReplyDeleteGuys. You have to understand one important detail: By using Moose in more and more modules, further and further down the toolchain, you effectively impose its use in more and more applications and eventually virtually all applications (from large apps like Padre to tiny helper scripts). This will have the effect that EVERY tiny little CLI tool will have a ~.2s lag to show the FREAKING HELP SCREEN!
ReplyDeleteThis is extremely noticeable for users. People have been very, very annoyed by similar lag introduced via PAR::Packer packaging of applications. .2s startup for every invocation of every Perl application is a very hefty price to pay just because people thought it a nice excercise to convert some existing code. And let's not even get into the issue of introducing extra, new bugs during such a transition.
By all means, use Moose in new code when you KNOW it's not going to matter if it takes a while to start. Don't start digging it into each and every module on the CPAN because you have NO IDEA where it'll end up being used.
@ahmad: yup. currently, padre starts up in 16 seconds here. granted, this includes opening my 20+ files with syntax checking.
ReplyDelete@brunov: app::persistent has not been yet released on cpan, and i don't know how it works with wx event loop + windows. maybe launching padre's app and reading config and all its stuff would works. it's definitely worth keeping an eye on it.
@tsee: i know, but keep in mind that a) i don't own any module that's hugely requested (which also explain why i never ever do testing release) and b) it's a chicken and eggs problem: no usage means no incite for moose people to focus on speed.
@tsee: Moose startup is a hard problem, but it is solvable. It is more a matter of tuits then it is anything else, none of us who know how to solve it have the them right now. I do agree that people shouldn't change old modules without first looking up the dep chain, but it is not really as apocalyptic as you seem to imply.
ReplyDeleteMy hopes is that by years end your worries will be a moot point because Moose startup will no longer be an issue (or at least will be minimized significantly).
can any one help me out to convert this perl code to moose. mail me at m_kalimullah@yahoo.com if possible..
ReplyDelete#in app/models/product.php
class Product extends AppModel
{
$name = 'Product';
$hasAndBelongToMany = array
{
'Sale' => array('ClassName' => 'Sale')
};
}
#in app/models/sale.php
class Sale extends AppModel
{
$name = 'Sale';
$hasAndBelongsToMany = array
{
'Product' => array ('ClassName' => 'Product')
};
}
@kalim: sorry, this is php code, not perl... and i don't think that moose exists for this language.
ReplyDelete