[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: ANSI Terminal Colors Module
- From: Rob Hoelz <rob@...>
- Date: Mon, 28 Dec 2009 14:46:05 -0600
On Mon, 28 Dec 2009 21:38:27 +0300
Alexander Gladysh <email@example.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
> 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. :-)
> 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
Thanks for the input!
Description: PGP signature