finally exporter with multiple inheritance bug is explained: class::accessor::fast version 0.34 now does some import magic, and in that case export's import sub is not called. so it's neither perl, nor exporter related.
but still, using multiple inheritance cannot be avoided sometimes...
2009-09-29
multiple inheritance - why still using it
ovid reacted to the bug i opened against exporter and multiple inheritance, stating that we cpan authors shouldn't use multiple inheritance, since roles exist.
with all due respect to ovid, this is over-simplifying. cpan holds 15000+ distributions, of which maybe 5% is proposing a role-based api (and i think i'm generous). which means that a lot of the modules available needs you to inherit from them[0]. so what to do when you want to use those modules? yup, multiple inheritance. i know it's bad - but i don't have the choice, mmk?[1]
i can already predict ovid's answer: my bug was related to inheriting from both exporter and class::accessor::fast[2], so i should switch to moose to replace the class::accessor bit. right, i plan to do it later on (patches welcome, too).
but in the meantime, i have a module that worked perfectly under 5.10.0, and that breaks under 5.10.1 (i am still not sure if it's perl or exporter or base/parent related). no need to talk of greypan and compatibility accross major perl releases: i'm talking of backward compatibility of minor perl version for regular cpan module with code available here. and even if it's using sub-standard technology - i am entitled to not expect this kind of breakage.
[0] which is not exactly surprizing, since roles are quite new in perl's oo landscape: 2.5 years according to moose's changelog. if you count some time to let the new feature stabilize, get some needed speed boost and gain acceptance, i don't expect to see a lot of non-role based api soon.
[1] i'm not advocating to use multiple inheritance at all costs. ovid is right: if you can, compose classes with roles. really, he is right on this topic. however, the key words here are if you can.
[2] see how both synopsis request you to inherit from them?
with all due respect to ovid, this is over-simplifying. cpan holds 15000+ distributions, of which maybe 5% is proposing a role-based api (and i think i'm generous). which means that a lot of the modules available needs you to inherit from them[0]. so what to do when you want to use those modules? yup, multiple inheritance. i know it's bad - but i don't have the choice, mmk?[1]
i can already predict ovid's answer: my bug was related to inheriting from both exporter and class::accessor::fast[2], so i should switch to moose to replace the class::accessor bit. right, i plan to do it later on (patches welcome, too).
but in the meantime, i have a module that worked perfectly under 5.10.0, and that breaks under 5.10.1 (i am still not sure if it's perl or exporter or base/parent related). no need to talk of greypan and compatibility accross major perl releases: i'm talking of backward compatibility of minor perl version for regular cpan module with code available here. and even if it's using sub-standard technology - i am entitled to not expect this kind of breakage.
[0] which is not exactly surprizing, since roles are quite new in perl's oo landscape: 2.5 years according to moose's changelog. if you count some time to let the new feature stabilize, get some needed speed boost and gain acceptance, i don't expect to see a lot of non-role based api soon.
[1] i'm not advocating to use multiple inheritance at all costs. ovid is right: if you can, compose classes with roles. really, he is right on this topic. however, the key words here are if you can.
[2] see how both synopsis request you to inherit from them?
2009-09-28
working around exporter bug in perl 5.10.1
exporter seems to have a bug with perl 5.10.1. in case of multiple inheritance, it must be the first parent, otherwise no export magic is done.
the bug is experienced both with base and parent, so i really think it's exporter related - or maybe 5.10.1, since it was not present with 5.10.0.
i reported the bug to p5p - in the meantime, just switch exporter to be the first parent in multiple inheritance...
the bug is experienced both with base and parent, so i really think it's exporter related - or maybe 5.10.1, since it was not present with 5.10.0.
i reported the bug to p5p - in the meantime, just switch exporter to be the first parent in multiple inheritance...
2009-09-23
external event loops no more part of poe
for those (such as me) that did not spotted it, external event loops for poe are now released as their own distribution. this means they aren't part of the poe distribution anymore, and you should add them to your prereqs...
of course, there's no way that dzil's autoprereq plugin could extract poe::loop::tk from code such as:
so, i had to use the regular prereq plugin to list it as a manual dependency. since dzil is using moose roles, it means more than one plugin can provide the prereqs, so i can continue using autoprereq beside this exception - woohoo!
in conclusion, games::pandemic 1.092660 is on its way, fixing a problem reported by a cpantester (thank you guys - you rock!)
of course, there's no way that dzil's autoprereq plugin could extract poe::loop::tk from code such as:
so, i had to use the regular prereq plugin to list it as a manual dependency. since dzil is using moose roles, it means more than one plugin can provide the prereqs, so i can continue using autoprereq beside this exception - woohoo!
in conclusion, games::pandemic 1.092660 is on its way, fixing a problem reported by a cpantester (thank you guys - you rock!)
2009-09-21
first external pandemic translation
i'm really happy to release a new pandemic version, namely 1.092640 (that is first release of 264th day of year 2009 for those that skipped previous entry).
beside the introduction of the medic player (which in itself is interesting), it's with great pleasure that i committed a japanese translation that tomita naoki provided me with. thank you tomita for this first external contribution!
so, if you want to contribute, an easy way to start is by providing a translation for your language! of course, any other contribution is also welcome. :-)
beside the introduction of the medic player (which in itself is interesting), it's with great pleasure that i committed a japanese translation that tomita naoki provided me with. thank you tomita for this first external contribution!
so, if you want to contribute, an easy way to start is by providing a translation for your language! of course, any other contribution is also welcome. :-)
2009-09-14
moosex::poe ftw!
in the serie "why using moose and moosex" - today i present moosex::poe.
say you want to create a poe session. traditional way is to create a module handling spawn method that would be called as:
the module itself would be something like this:
now that's moutful. and it has an easy-to-miss error - found it? right, it's should be event3, not evnet3. you can curse poe quite some time trying to understand why your nice handler never gets called for event3.
here's the version using moosex::poe:
of course, it's still possible to mis-spell event3. however, you only have to spell it once, whereas you wrote it 3 times before - which is 2 times too much!
and i'm not talking about the easy accessors that could be added by moose - but i'm concentrating on moosex::poe here.
granted, there's one downside: subs are now anonymous, which can make it a bit harder to debug. but that's a small price to pay, imo.
so, moosex definitely makes your code more readable - i'm definitely not looking back, and i advise you to have a look too.
say you want to create a poe session. traditional way is to create a module handling spawn method that would be called as:
the module itself would be something like this:
now that's moutful. and it has an easy-to-miss error - found it? right, it's should be event3, not evnet3. you can curse poe quite some time trying to understand why your nice handler never gets called for event3.
here's the version using moosex::poe:
of course, it's still possible to mis-spell event3. however, you only have to spell it once, whereas you wrote it 3 times before - which is 2 times too much!
and i'm not talking about the easy accessors that could be added by moose - but i'm concentrating on moosex::poe here.
granted, there's one downside: subs are now anonymous, which can make it a bit harder to debug. but that's a small price to pay, imo.
so, moosex definitely makes your code more readable - i'm definitely not looking back, and i advise you to have a look too.
2009-09-07
full pandemic stikes, woohoo \o/
erm, not this pandemic, but the pandemic game written in perl...
so yes, i'm happy to report that milestone 1.01 has been reached. indeed, here's what warrants the bump:
however, all in all, i'm quite happy (and proud) of the release. version 1.0 is definitely not the ultimate one, it only means that you can play with it with comfidence.
of course, i'm always eager to have (constructive) feedback2 on it. and if you want to contribute, well, the source is available on github.
[1] in fact, it's 1.000000 (i know it's ugly) since i'm switching to rjbs' versioning scheme: 1.yydddn3. it'll make versioning boring (even if not beautiful).
[2] fan & love mail is ok too :-)
[3] yes, i'm taking every bad habit rjbs has to offer, as long as it helps my laziness. of course, games-pandemic is using the excellent dist-zilla since the beginning.
so yes, i'm happy to report that milestone 1.01 has been reached. indeed, here's what warrants the bump:
- infection rate grows as epidemics strike
- special event: airlift implemented
- special event: forecast implemented
- special event: government grant implemented
- special event: one quiet night implemented
- special event: resilient population implemented
- epidemics now shown in past cards
however, all in all, i'm quite happy (and proud) of the release. version 1.0 is definitely not the ultimate one, it only means that you can play with it with comfidence.
of course, i'm always eager to have (constructive) feedback2 on it. and if you want to contribute, well, the source is available on github.
[1] in fact, it's 1.000000 (i know it's ugly) since i'm switching to rjbs' versioning scheme: 1.yydddn3. it'll make versioning boring (even if not beautiful).
[2] fan & love mail is ok too :-)
[3] yes, i'm taking every bad habit rjbs has to offer, as long as it helps my laziness. of course, games-pandemic is using the excellent dist-zilla since the beginning.
2009-09-01
migrating to moose? hell yeah!
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...
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:
Posts (Atom)
