Next message: Tony Cook: "Re: Imager-0.38pre9 Released."
> This really is the last version (we hope) before a CPAN release. The ONLY
> changes from this release to the final CPAN version should be to iron out
> things like Imager not looking for the libraries in the default location
> for that particular platform.
> It would be really appreciated if everyone could give it a go and report
> success or problems on the list.
Before this goes public on CPAN, I was wondering if you would consider doing
a named parameter cleanup?
I know that Color is at least one example of where this could be improved...
Currently the Color constructor can take parameters in the following ways
$color = Imager::Color->new($red, $green, $blue);
$color = Imager::Color->new($red, $green, $blue, $alpha);
$color = Imager::Color->new("#C0C0FF");
What if I want to pass in an html color spec with an alpha channel?
The sample for the docs above might become:
$color = Imager::Color->new(-red=>$red, -green=>$green, -blue=>$blue);
Imager::Color->new(-red=>$red, -green=>$green, -blue=>$blue, -alpha=>$alpha)
$color = Imager::Color->new(-htmlcolor=>"#C0C0FF");
Only now I can pass an html spec and alpha:
$color = Imager::Color->new(-htmlcolor=>"#C0C0FF",-alpha=>$alpha);
It would be nice to have all the public functions use named parameters for
consistency rather than some with and some without. It might also make
reverse compatibility less of a problem once you go public on CPAN and later
add to this module.
Also, a side benefit of named params is that if good names are chosen it
makes the code and the interface somewhat self-documenting. It would be
nice to go through and rename some of them. (I would probably change aa to
antialias, for example.)
It will break some existing code, but better now that after it goes to CPAN.
Does anyone else think this is worth doing? Is it worth it for you to
change some of your code to improve the interface? If so, voice your
opinion now, because once it goes to CPAN, it will be much harder to justify