Feature Private functions in ash scripts

[StDoodle]

Title pretty much sums it up. The two main reasons are:

1) I like to write a few helper functions to be used by the "public" functions in my imported scripts that could easily cause errors if they weren't used "correctly." Generally, I try to code them so that this won't happen, but many times it's a significant difference in coding to make such a function near-foolproof vs. making it foolproof for how it's being used by other "public" functions in the script.

2) It would be nice to have such "private" functions hidden in the list of functions shown with a "verify" cli command.

If this would be something that could be added as a feature, I would be happy with pretty much any formatting requirement for the declaration of functions as private, from something as simple as adding "private" before the declaration, to as complex as some weird string of characters having to occur at a certain point in the function name.

 

[Bale]

to as complex as some weird string of characters having to occur at a certain point in the function name.

Well, if you're happy with something as outrageous as that, then perhaps you should have an extra string parameter called code, and check it in the body of the function. If code isn't correct, it aborts. That'll at least force people to do some research before using your private function.

That should be enough to keep the clueless from using such things though I doubt the clueless would even try to use such undocumented features.

 

[StDoodle]

But there's really no way to obfuscate what code has to be, so it would be trivial for a user to supply such a parameter on their own.

I mean, yeah, it's not necessary, but then, you could technically argue that private functions / methods / etc. are never necessary, yada yada. Hell, one could argue that assembly is much higher-level than necessary.

That's not to say I'm clamoring for "add this now!" I'm just saying, I would find it useful.

 

[Bale]

But there's really no way to obfuscate what code has to be, so it would be trivial for a user to supply such a parameter on their own.

Yeah, I'm just saying it would stop anyone who didn't actually look at the code. If they look at the code then they should have a clue what they're doing so they don't screw up the function. Think of finding the code as an entrance exam. If they like it that much they can copy-paste it into their own script, so why stop them from using it once they pass the entrance exam?

 

[StDoodle]

True enough. At that point it's more of a "I won't document them, and mention on the documentation that if you complain about bugs in undocumented functions used independently I'll go la la la."

 

[fronobulax]

I don't see the value. There is no way to distribute the script without including the source in plain text. It seems your real problem is that you are willing to support external use of some of your functions, but not all of them. A comment to that effect in the code would probably be sufficient. At the risk of encouraging the proliferation of lots of little files, you could always stick the unsupported ones in a separate file - std_privates.ash, for example ;-)

Personally I would much rather import something that you maintain than copy and paste your code and then have to maintain it myself.

 

[StDoodle]

As an example, the map_to_csv() and csv_to_map() functions in my std_lib.ash are used by the get_csv_property() and set_csv_property() functions. Rewriting the latter to get rid of the former would be inefficient and cause horrid code bloat. However, re-writing the former to be robust enough not to break easily on improper input would be a huge pain, and likely just as much code bloat.

But yeah, I guess I'm being too paranoid... the comments should be sufficient. Anyone who knows enough to dig around in the file and try to use the undocumented pseudo-private functions will likely know enough not to complain if they break with improper input.

 

[HippoKing]

Have you considered a comment which says "This function is not supported for external use: if it breaks, this is your fault and I will laugh at you"?

I don't really see why it is your problem if someone else downs up doing unsupported things with your script.

 

[xKiv]

The value of private functions in source-distributed scripts is more that you don't have to worry if someone else's script in the same execution environment has same-named function with different meaning.
Though in the case of mafia, you are not supposed to have more than one script with the same name, so using script name as a prefix should probably work for that.

 

[bordemstirs]

so it would be trivial for a user to supply such a parameter on their own.

Just as trivial as it would be for the user to delete the word "private" from the source.

 

[Veracity]

The value of private functions in source-distributed scripts is more that you don't have to worry if someone else's script in the same execution environment has same-named function with different meaning.

Exactly, and I think this a reasonable request for exactly that reason. If somebody wants to take your private "helper" function and remove the "private" keyword from the definition, it's their own lookout as to whether it conflicts with anything else their script also loads and defines.

Though in the case of mafia, you are not supposed to have more than one script with the same name, so using script name as a prefix should probably work for that.

Yes, that is the workaround with current code.

I still rather like a "private" declaration for functions and variables and associated single file scope.

 

[StDoodle]

Ooh, I forgot all about variables, but that's another thing I'd really love to see; some of my functions make use of certain variables to control their behavior, and while I doubt anyone will be using "boolean _batch_zlib_save" in their script, I'd feel a lot safer knowing that I would never be an issue.