module advice

[robobunny]

I'm working on a module called Text::Anim, to do something akin to sprite animation with ASCII art. It can be used to do a standalone full screen animation, or it can be passed a Curses window, so that you can insert an animation into a window inside your Curses application. Any advice would be appreciated, particularly from anyone who has done sprite animation before. Here are a few specific things I'm interested in:

1) What features would you expect or like that are missing?
2) Is there anything that goes against conventions for sprite animation in a way that would confuse someone with sprite animation experience
3) A better way to implement the get_path routine without passing so many arguments (maybe a hash like the routines in CGI.pm?)
4) Any problems that you run into trying to get it to work

Here is the module and a demo script. There is a small example script at the end of the module. Curses is required for the module, Geo::Weather is required for the demo script.

[Ovid]

Regarding your constructor:

sub new {
  my $proto = shift;
  my $class = ref($proto) || $proto;

Please do not use ref($proto) || $proto unless you need it. It serves no purpose in your code.

Other than that, while I haven't played with your module, I must say that the basic premise looks like a lot of fun :)

Update: Yeah, what tye said! :)

Cheers,
Ovid

New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)

[tye]

If you are going to spout this oft-disputed advice, then at least tell them what you want them to use in place of the part you don't want them to use.

If you are suggesting my $class = shift; instead of the two lines (so no $proto at all), then you should also tell them to document that $obj->new() will silently do ugly things, creating a broken object that will likely cause confused error reports from users of their module.

Which certainly suggests to me a reasonable "purpose" for using the simple and defensive code that is suggested in the standard documentation, as the original poster did.

No, I really don't want to rehash this argument for the Nth time in this thread. Some feel strongly that $class = ref($proto) || $proto is a bad thing™. Some feel strongly otherwise. My point was that your incomplete advice in advocating your position was probably not very helpful to the original poster.

Feel free to advocate what makes sense to you. But please also say what to use not just what to not use and be aware of why this advice is often disputed and let them know what the down side of your suggestion is or link to one of the several long previous discussions of the issue. (:

                - tye

[scrottie]

Generally speaking, when methods require too many arguments, thats a symptom of a God Object. Refactoring a God Object is going a few steps past the "Currying" concept. In a nutshell, objifying more things gives you grainularity on state. Using one large object prevents structure form arising out of the chaos of your program (well, any program, I'm just being dramatic). Good user interfaces often take the form of creating one object, passing it options, then passing that object as an option to the constructor of another object. Each object contains configuration associated with what it represents in the world, and part of the configuration of other objects is the configuration already performed on existing objects. Pod::Tree and its related modules are an example of this. Feel free to email me at [e-mail] or markup the wiki pages at perldesignpatterns.com - I don't read comments, only headlines, and only sometimes. And whoever is doing that thing that gives me experience, stop it! I'm trying to lay low. -scott