Re: ANSI Terminal Colors Module

[Rob Hoelz <rob@...>]

On Mon, 28 Dec 2009 21:38:27 +0300
Alexander Gladysh <agladysh@gmail.com> wrote:

> >>> Also, I'd like to have color constants visible from outside the
> >>> module, in case I'd ever want to implement my own makecolor.
> 
> >> What kind of makecolor adaptation did you have in mind?
> 
> > Well, nothing in particular right now. But I think that those
> > constants do have value for themselves.
> 
> I'd like to add to my answer. :-)
> 
> The makecolor() as it is now is fine and clever, but I see several
> small performance problems there. This is unnoticeable in most
> use-cases, but sometimes people need every drop of performance.

I figured I'd just start simple, but feel free to optimize! =)

> 
> For example, in functional form, it concatenates string:
> 
>     function colormt:__call(s)
>         return self .. s .. _M.reset
>     end
> 
> This would create extra garbage. Also I see here an extra __concat()
> metamethod call.

As far as extra garbage goes, you'll be creating a new string no matter
what.  Unless I'm missing the point...

> 
> Also, __concat unnecessarily calls __tostring on self (it could just
> use self.value).  Also, self.value could be self[1]. :-)
> 
> For the use-cases when performance is critical (like log parsing and
> highlighting), I'd like to have less convenient, but faster interface.

You could always do local red = tostring(color.red) (not exactly
intuitive to read, though), or maybe I should add color.raw.red?

> It is not necessary at all that such interface should be a part of
> your module. But, by exporting constants (and that "magic"
> concatentation from makecolor()) you'd increase reuse. It is probably
> better to split ansicolor to two modules then, one high-level, one
> low-level.
> 
> Alexander.

Thanks for the input!

Attachment: signature.asc
Description: PGP signature