(none) imager-devel
/ help / lists / applications / search /

Re: Imager-0.38pre9 Released.

From: Tony Cook (
Date: Sat 19 May 2001 - 03:28:15 UTC

  • Next message: Mike Depot: "Re: Imager-0.38pre9 Released."

    On Fri, 18 May 2001, Mike Depot wrote:
    > 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
    > (from docs):
    > $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);
    > $color =
    > 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.

    Would you object to Imager::Color accepting both type of interface?

    We only get the problem of distinguishing between:

      $c = Imager::Color->new(red=>100, green=>0, blue=>255, alpha=>128);


      $c = Imager::Color->new('red'); # lookup in /usr/X11R6/lib/X11/rgb.txt?

    though this shouldn't be a big deal (if we ever happen to support the
    second interface).

    We could distinuguish between the 2 by requiring the '-', but then we'd
    have to rework all the existing named parameter code for consistency.

    In any case I can't see it going into 0.38, since the idea at the moment
    is to get a stable CPAN release out, and then start fiddling again.

    Whether it goes in at all is of course up to Addi.

    > 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
    > changes!

    The existing interface is used in the version currently on CPAN, this
    isn't really a valid argument.

    Future additions to the interface are likely to use named parameters.