- Joined
- Jul 10, 2007
- Messages
- 6,306
However, that doesn't really apply to this script. The script is quite literally a multiboard wrapper. If you know how multiboards work, you know how this script works. It has all the same features and operates in the same fashion (except that the multiboard items are cached to make retrieval of them faster/easier).
I'm personally of the thought that common data structures, like stacks, dequeues, queues, or multiboards (in this case) shouldn't have their operations described in the docs. It's up to the user to already know what they are given that they are rather standard data structures. If it was something completely new, then the operations should be explained in the docs. There are plenty of tutorials out there that will do a lot better job explaining something like a stack than some docs in the header of a stack script. It isn't a script's job to be a tutorial for standardized things, heh.
Now, if you want a prime example, look at String Parser. I really did write a massive tutorial about what String Parser is and how to use it. The header only contained the API. All of the information on how to use it was in the tutorial. This falls in line with exactly what I said.
This style makes it easier for people to learn the API of new resources that already know how that resource operates (Multiboard in this case). It also makes it easy for people to learn the resource who don't already know how it operates (the massive in-depth tutorial, which beats header docs any day of the week).
Now, as I said, I think the primary issue here between whether a user would want to use this or Board is Board's required use of ARGB. If they are already using ARGB or are planning on using ARGB, then Board is a good way to go. If not, they might as well use Multiboard. If Board was made optional, then the only dif between the two would be speed really >.>. I personally prefer a faster smaller script since I'm a perfectionist, but that's just me. As I said, if I'm the only one who'd use this script, then just gy it. If other people want to use it, then keep it up as there is no reason to gy it >.<. It's pretty simple.
I share anything that I write that appears to have a general use to it, regardless if scripts were already up or not. If I wrote it, then I either didn't know that the other scripts existed or I didn't like the other scripts for some reason or another. It just makes sense to share stuff you do, there is no reason not to >.>. If people don't like it or don't want to use it or prefer that other script, then it just gets gy'd and that's fine. If they do like it, then gj on sharing.
I'm personally of the thought that common data structures, like stacks, dequeues, queues, or multiboards (in this case) shouldn't have their operations described in the docs. It's up to the user to already know what they are given that they are rather standard data structures. If it was something completely new, then the operations should be explained in the docs. There are plenty of tutorials out there that will do a lot better job explaining something like a stack than some docs in the header of a stack script. It isn't a script's job to be a tutorial for standardized things, heh.
Now, if you want a prime example, look at String Parser. I really did write a massive tutorial about what String Parser is and how to use it. The header only contained the API. All of the information on how to use it was in the tutorial. This falls in line with exactly what I said.
This style makes it easier for people to learn the API of new resources that already know how that resource operates (Multiboard in this case). It also makes it easy for people to learn the resource who don't already know how it operates (the massive in-depth tutorial, which beats header docs any day of the week).
Now, as I said, I think the primary issue here between whether a user would want to use this or Board is Board's required use of ARGB. If they are already using ARGB or are planning on using ARGB, then Board is a good way to go. If not, they might as well use Multiboard. If Board was made optional, then the only dif between the two would be speed really >.>. I personally prefer a faster smaller script since I'm a perfectionist, but that's just me. As I said, if I'm the only one who'd use this script, then just gy it. If other people want to use it, then keep it up as there is no reason to gy it >.<. It's pretty simple.
I share anything that I write that appears to have a general use to it, regardless if scripts were already up or not. If I wrote it, then I either didn't know that the other scripts existed or I didn't like the other scripts for some reason or another. It just makes sense to share stuff you do, there is no reason not to >.>. If people don't like it or don't want to use it or prefer that other script, then it just gets gy'd and that's fine. If they do like it, then gj on sharing.