Comments (3)
I was thinking about this for quite some time. Here is my suggestion.
Version 2.0 receives no further features, fixes, etc except those that are critical and no easy workaround can be found. For instance, for the issue here you can easily rename 'command' to 'command_name' or sth else. Or for #41 you can end all named parameters sections in functions with a :
and you are good to go.
For version 3.0 onwards, I suggest a slight change in the development approach. I think that we should aim for the framework to be written from scratch. Just to not create unwanted impressions, what you have already achieved is one hell of a clever project and I still stand in awe of your achievement. By rewriting, I simply mean to start from an empty state, not try to just patch the previous version. We can start from the entry point of the project (oo-bootstrap) and move to each module one by one. Code reuse could, will and should happen, but at every step there should be 3 criteria on whether to commit (old or new) code:
- Code is sufficiently documented: Comments on difficult hacks, on what info some key variables hold, how some functions work, etc should IMO be included. We could also use (and extend) sth like this and have a really well documented project. This could lower the entry barrier for new contributors, as well.
- Code is thoroughly tested: We should try to have as good test coverage as possible. Bash infinity is one hell of a project with great logical complexity and there are many edge cases. Having tests that go through every small or big part of functionality will give as assurance that our approaches are correct and will also bring confidence to potential users that the framework is stable. There could also be a CI process in place.
- Code should be >adjective-here<: By that I mean we should try to write clean, short code that follows a consistent coding style, ideally is benchmarked, etc. The unofficial strict mode could also be adopted.
While developing, tools like shellcheck, shfmt, etc could be used to help produce as quality code as possible. Also, a git workflow (eg gitflow) could be adopted.
Moreover, it seems important to me to place Bash Infinity into a broader ecosystem of bash projects and cooperate with some significant ones (like BATS or go-script-bash). Technically, this translates into two things:
- Making integration easier with such projects should be a consideration.
- Functionality that is already covered by other such projects, should not be repeated, unless we feel that Bash Infinity's approach is better. For instance, BATS is a complete testing framework. Having our own, does not really add value to the end user and is an extra burden on maintenance. Instead, we could make it as easy as possible to integrate Bash Infinity with that project as per 1. . On the other hand, go-script-bash has an import functionality similar to Bash Inifinity. However, the approach there wouldn't suit Bash Infinity's needs, plus Bash Infinity's approach is more flexible.
Another issue to consider is platform and bash version support. From my point of view, someone that wants to use Bash Infinity to develop a bash project will have no problem updating their bash version to the latest available. It would be surprising to see someone choose to develop a whole project/application in Bash plus try to reduce development pain with the use of a framework and yet have issues updating their bash version. Thus, I think that development should be more or less done against the latest Bash version.
Finally, sth that is more like a wish of mine is to make it easier to use the project by providing stuff like syntax highlighting and auto-completion files for eg vim or atom.
The above are some thoughts I have been having and if you agree on some we could further discuss them and act upon them. Time is a scarce resource but there is no hurry here. I am interested and willing to help build little by little the new version.
from bash-oo-framework.
Fix is here, in the rewrite of the named parameters functionality: #41 (comment).
To get it merged I'd need to provide a backwards-compatible layer for the older syntax, I didn't have time to do it yet. Unless we do it as a breaking change and release 3.0. What do you think?
But it works with the new version:
function q {
args : @required string command
echo "${command-UNDEFINED}"
}
q 'some value'
Prints: some value
from bash-oo-framework.
Great points @tterranigma!
I wholeheartedly agree about the clean-slate and all of your criteria for it.
Just as I've started with the re-write of named parameters -- a clean slate here really helped to create a much shorter and easier to understand code.
Similarly, I've been experimenting with a better importing system, which does not pollute the global scope. See the example here.
Regarding your last point, I've also been exploring the "better tooling" avenue -- the experiment was to try and re-use tooling from a different language. My first try is to adapt TypeScript, i.e. use a limited set of expressions and emit clean bash
.
It's a wild project, but I've already got something running locally -- it's a different take on the issue, and possibly a separate project to Bash Infinity.
But going back to the idea of 3.0 -- let's do it! 🔥
from bash-oo-framework.
Related Issues (20)
- Is the project dead? HOT 3
- Sorry, a bit cheeky/impolite... HOT 2
- error handling with throw / command_not_found_handle HOT 3
- Unbound variables cause a crash when running examples with 'set -u' HOT 3
- [bug?] `throw` is said to be 'undefined command' when `import` fail HOT 5
- Catch exception from Classes doesn't work HOT 7
- Inconsistent array assignments HOT 3
- Translating README into Japanese
- for people who want to use Bpkg to install this framework HOT 1
- example/trycatch.sh doesn't work as expected
- Make wiki page
- [Question] Does value of '__primitive_extension_fingerprint' have special meaning?
- update readme instructions for namedParameters
- util/exception.sh shows stack trace as expected but don't exit on Ctrl+C HOT 2
- False boolean not working HOT 1
- Referring this in Human example class doesn't work as described HOT 1
- Exception messages are invisible in light theme mode in Shell console.
- [Question] Is this project still alive? HOT 6
- [Discussion] Log API
- Using a variable for an Object name
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bash-oo-framework.