# from José Castro
# on Monday 25 July 2005 07:49 am:
>Acme::TabulArt # doesn't explain what it does
>HTML::ASCII2ColouredTable # weird name :-\
Is the ascii input the only way to drive it? Maybe it could be done
with other image formats too? To me, it really looks like an image
routine (though the HTML table output is a rather specialized form of
image.)
Image::TableArt
Image::HTMLTable # at risk of being confused with a tiler?
HTML::InlineImage
HTML::TableArt
I don't think ASCII is an appropriate part of the name. Mainly, because
I don't think that should be the only way to get your input.
>I also need a name for the main function...
>
>table # not descriptive
>ascii_image_2_html_coloured_table # too descriptive
>ascii2table # could this be it? :-\
Depends on how/where you want it to grow. I think ascii_to_table might
read better. That you call it the "main function" sounds suspicious --
like that's all this module will do. I think too many modules follow
the pattern of being named Module::DoesStuff and having one function
named do_stuff(). This is appropriate in some cases, but in this case
it seems like the functionality is going to be on an island (i.e.
everyone who uses it has to build a bridge.)
You might look at CAD::Drawing::IO and the backends under that. The
functions are just named load() and save() but they let you specify
what type (file format) to use. Also see Image::Magick, which has
format-agnostic function names. If you decide to take this approach,
ascii_to_table() could just be a convenience function where the
source/destination formats are coded as the function name rather than
as parameters. Maybe it would then look something like this:
# =========
sub ascii_to_table {
my ($string) = @_;
my $obj = Image::TableArt->new($string);
return($obj->as_html_table);
}
# =========
I would actually like to see these two formats added to Image::Magick.
Have you considered that possibility?
--Eric
--
"But as to modern architecture, let us drop it and let us take
modernistic out and shoot it at sunrise."
--F.L. Wright
---------------------------------------------
http://scratchcomputing.com
---------------------------------------------
