Options
NetLinx string manipulation library
PhreaK
Posts: 966
Continuing on with the friday open source love I thought I'd expose my string manipulation library to the world. It's a bit kludgy at the moment, and far from optimised, but it's functional.
http://code.google.com/p/amx-netlinx-string/
*Edit*
This has now merged into the NetLinx Common Libraries project.
At this point in time it provides you with functions for:
- string array implosion
- printable character check
- left trim
- right trim
- trim (left and right)
- boolean to string
- string to boolean
- integer array to string
- the ability to retreive a 'list item' as seperated by an arbitary delimiter
- key / value pair retreival
- date inversion for switching between US and international standards
- retreive a string bounded by two arbitary sub string
- capitilise the first letter of a string and convert the rest to lower case
As with the math library everything is documented in a javadoc-ish type way so feel free to poke.
Again, enjoy.
http://code.google.com/p/amx-netlinx-string/
*Edit*
This has now merged into the NetLinx Common Libraries project.
At this point in time it provides you with functions for:
- string array implosion
- printable character check
- left trim
- right trim
- trim (left and right)
- boolean to string
- string to boolean
- integer array to string
- the ability to retreive a 'list item' as seperated by an arbitary delimiter
- key / value pair retreival
- date inversion for switching between US and international standards
- retreive a string bounded by two arbitary sub string
- capitilise the first letter of a string and convert the rest to lower case
As with the math library everything is documented in a javadoc-ish type way so feel free to poke.
Again, enjoy.
0
Comments
As to the actual content itself:
* Your trim functions return "printable characters" rather than how most implementations are documented as working; as in removing only space, tab, lf, cr, htab.
* Formatting - You don't have tab settings information in your header comment. It looks like some tabs may be missing? but maybe it's just me...
* Comments for stringGetKey and stringGetValue are wrong.
* I guess I don't see how stringGetKey or stringGetValue works. Is it expecting one key:value pair seperated by the delimiter you specify?
I have a string explode function you may want to add. I didn't know AMX had one before I wrote mine (meaning they had code in a technote to do it), but even then, AMX doesn't sanitize the array (optional with mine) nor does it handle quoted strings (currently mandatory but will wrap so a different function call won't honor it). I can modify it for performance and send you a patch if you want. I also have other useful string functions: prefix string to length, suffix string to length, base64 encoder/decoder, etc...
(Also PM me for user/pass if you want commit access on the repository I put up.)
As far as what you've pointed out:
* camelCase - I've always just used it for function calls, although the native 'underscored' style may be better to help keep conformity with the rest of the language so I'm open to changing it. That being said, it is something that will have to be defined and stuck with form the site so that future revisions don't break implementations
* trim functions - again, will need to be changed
* formatting - the code has all been formatted to look pretty with the consolas typeface and tab stops at 8 characters
* comments - I'll get these fixed straight away
* stringGetKey and stringGetValue - these were designed primarily for processing string data passed back from duet modules but I tried to keep them flexible enough for use in other situations. For example the string 'FOOBAR-Hello world' would be extracted to a key of 'FOOBAR' and a value of 'Hello world' using the delimiter '-'.
I've added these issues to the project issues tracker and I'll update them as they're resolved.
It sounds like you've got some other useful functions, if you're happy contributing them to the project that would be great. If you've got a Google account shoot me your email and I'll add you as a contributor so that you can modify at will. This offer also stands for anyone else who would be interested in shaping the way this develops.
Also, cheers for the offer to utilize your repo but I'd been keen to try and keep these running on Google code as it provides a svn server, wiki, issues tracking, etc all in centralized location without the need for external management and maintenance.
I figured that is how it was, I just wanted to confirm it was one key,value pair in a string.
I'll do that soon (at work right now).
I was going to put a bugtracker of some sort up as well. Repos would be a user-folder public sandbox (so you'd be located at /phreak or whatever you want, and would have the same for the bugtracker) and could be used for projects you just want to throw online without thought. It doesn't need to host stuff you'd like to do elsewhere.
check out trac it's a pretty commonly used system and I like it a lot
The way I've been using it is to use stringGetKey and stringGetValue functions to split out anything returned from my modules, use the key to branch on and then use stringGetListItem to pick out specific parameters I want.
Also, with the project hosting I'm still pretty keen to keep this guff with Google Code or similar as it is independent to any of us, not that I don't trust people but Google is less likely to disappear or experience downtime and system faults. If you haven't used it before jump in and have a look, its all put together really well and there's loads of support.
Just a little heads up for those not on the dev mailing list and had downloaded a copy of the string library. There were a few issues in the original verison (as noted by true). Everything has now been fixed and should be playing nicely. If you're so inclined you can see what has been modified here. The project download has been updated with the newest version too.
I plan on committing some changes in the next couple of days. I would have done it tonight but I forgot the dev notebook at the office...
Also, why not create just a netlinx-library project or something instead of having multiple single-file library projects?
I find camel case much easier to read and type. I use it for almost everything.
Wikipedia has a decent entry as to why:
"The underscore key is inconveniently placed on QWERTY keyboards. Additionally, in some fonts the underscore character can be confused with a minus sign; it can be overlooked because it falls below the string of characters, or it can be lost entirely when displayed or printed underlined, or when printed on a dot-matrix printer with a defective pin or misaligned ribbon. Moreover, early compilers severely restricted the length of identifiers (e.g., to 8 or 14 letters), or silently truncated all identifiers to that length. Finally, the small size of computer displays available in the 1970s encouraged the use of short identifiers. Many C programmers opted to use camel case instead of underscores, for it yielded legible compound names with fewer keystrokes and fewer characters."
The fact that it isn't native seems to me to be arbitrary. Most of the standard NL calls I've wrapped in functions using camel case anyway so the code all looks similar, like C code. I never call FIND_STRING(), I call find() instead.
Paul
I've started thinking that myself actually, might make ongoing maintenance etc a bit easier. The main reason I went for discreet projects was to keep things like the issue tracker relevant to that project and make sure we maintain seperation between the libraries for portability reasons.
Again, no one is going to be entirely happy with the coding style used, but it is definately something which we should discuss and take a democratic approach to.
Generically, non-OO languages don't use camelcase, and OO languages do (with conventions for use). I tend to stick to the conventions of the language in use, unless they're demonstrably wrong or none exist, in which case I fall back on what I can find based on syntax, function calls, etc. and what similar languages use. In the case of NetLinx, builtin functions aren't in camelcase. I don't mind reading general code with it, but I don't think it fits with a standard library.
And I don't blame you for wrapping some NL functions - find_string() is a good example where find() would've worked just as well. Sadly, most common functions in NetLinx are this way