Why are UI.Color members aliases?

[nkakouros]

I am in.the process of incorporating this framework to a project of mine. I used to have a file full of color definitions in the form of variables. I saw that you provide colors as aliases that use echo. Is there a benefit in doing that? My (naive) intuition that variable should be even a little faster.

[niieani]

If I recall correctly, the only reason they're aliases is to match their APIs with other types (i.e. they contain dots). Variables can't contain dots. There might have been another reason, but I don't remember at this moment. But you're right, variables access should be a bit faster.

There are also opportunities for better APIs al round, so I'm open for improvement pull requests. 👍

Thanks.

[nkakouros]

I run some quick tests and I got these results:

$ time for i in {1..1000}; do echo "$( UI.Color.Green )">/dev/null; done

real    0m7.873s
user    0m0.139s
sys     0m7.782s

$ time for i in {1..1000}; do echo "${green}sfg">/dev/null; done

real    0m0.009s
user    0m0.007s
sys     0m0.002s

This is pretty significant!

I don't want to dictate what happens in the project. I will simply prepare a PR adding a file with variables instead of aliases and maybe it could exist side by side with the alias version. The only option is the underscore, so the variables will look like UI_Color_Green.

Indeed, UI.Color.Green looks way more appropriate but it feels like the performance overhead is too large. Also, scanning the README, the only other place where dots are used is in class method names. Maybe then it doesn't take away too much of the API stylistic cohesion.

[nkakouros]

I just pushed #30, but it was a hasty one. As I will spend some time getting acquainted with the project, I would like to ask what are the goals for Bash Infinity. Is it providing an OO-looking API as much as possible? Is it to be fast? Cover common bash scripting needs? Thanks for the attention and sorry for the spam.

[niieani]

Thanks, I've merged it.

The main goal is to provide a better experience writing shell scripts, hence the better stack traces, positional arguments, try/catch, and beginnings of a standard library (obviously unfinished). I didn't give much attention to performance, since it was adequate (i.e. the performance impact was invisible, which I consider good enough for most scripts). Possibly not good enough for performance sensitive work, but then again, I've never came across a use-case for bash, where performance would be a concern.

Since the time I've worked on the framework intensively, I've re-evaluated some of the ideas and now, I'd probably focus less on the OO aspects and more on the functional/immutable possibilities.

I also had the idea to make a transpiler from a typed language into bash (kind of like TypeScript or Reason with a bash output as a target). It could be cool, but then again, my needs have changed and I do not need bash that much. But bash is still kind of like "the JavaScript of the terminal", in the sense that it is available in so many systems, it provides a universal good platform for developers/admins, just as JavaScript does for the end-users (runs on desktops, mobiles, TVs, etc.).

I'm curious, what are the problems you are trying to solve in your scripts, and what drove you into using Bash Infinity?

Cheers

[nkakouros]

I am working on a project where bash is like 1/3 of it. I was in the process of writing tests using bats and refactoring the code all over the place to better support this and I found myself

• trying to build a color library
• repeating checks for function arguments
• fighting to get a decent stack trace.

Searching for libraries I stumbled upon your framework and I thought it would be good to use Infinity to have a nice, stable base to build on.

Moreover, I think that it could be a reference framework for bash and together with other projects like bats, go-scripts, etc can provide a nice package for bash programmers. But for that, as I learnt from bats, there needs to be documentation, performance tweaking, code cleaning, etc. I mean you have done an amazing job, but there are some TODOs left in the code and some edge cases left. That's why I asked about the project goals.

[niieani]

Yeah, I completely agree with your points. Docs could be better and more complete and there is still a bunch of stuff to polish, think about API design (like naming) and so on.

If you'd like, I can make you a collaborator on the project if you'd like to improve on any of these points.

[nkakouros]

Sure, I'd be glad to help as much as I can. But I will spam you with questions a little more until I get a good grasp of the code!