# Hiding certain user-defined functions in front-end autocompletion

I have written an elaborate code that contains a collection of functions for the user and a bunch of auxiliary functions whose existence I would like to hide away from the user. I've written my code in a separate .nb file which I run. I intend the user to do work on a separate clean notebook.

But in v9, when I (the user) starts typing something that resembles one of these auxiliary functions, it appears in Mathematica's autocompletion bar. Is there a way for me to 'hide' these functions, while keeping the ones that are intended for the user?

For example, I have defined:

fooAuxiliary[n_] := (-1)^n*HarmonicNumber[n+1];

foo[x_] := fooAuxiliary[Floor[x]]*Sin[x]


with the user given access to call foo but not fooAuxiliary.

-
Does it show up in the suggestion bar or in the autocompletion? I think you mean the latter... If you write a package and put the auxiliary functions in a private context, then the autocompletion only shows the functions that you've exposed publicly (although, they can autocomplete the others if they add the private context too) –  rm -rf Jan 25 '13 at 2:26
Oh sorry, yes; I meant the autocompletion. I will make edit. But I also don't know how to write a package... –  QuantumDot Jan 25 '13 at 2:28
@NickStranniy, why did you delete the answer? –  Rojo Jan 25 '13 at 2:57
@Rojo Possibly because the OP's tone seemed like they were mocking the answer... –  rm -rf Jan 25 '13 at 16:47
@QuantumDot I think you should just write a package and leave fooAuxiliaryfunction in the Private context of the package. –  Ajasja Jan 25 '13 at 17:12

In addition to the suggestion of using a separate context (which I think is a good one), in the answer by Nick Stranniy, you can use some of the OO extensions which allow one to call methods on some objects (instances). In this way, method names themselves will not have any definitions, so effectively the implementation gets hidden. If the user is determined, s/he can still reverse-engineer this, but it is harder and one has to understand the inner workings of such OO extension.

For example, the one I described here will do. Here is a simple example. Assuming that you installed it (installation instructions on the GitHub page for it linked to from the mentioned answer), first we load it:

Needs["OO"];
$ContextPath = DeleteCases[$ContextPath, "OOMethods"];


The second line is needed to avoid shadowing, but is not strictly necessary if the code is in some package / context. Now, here is a simple class (type) definition:

DeclareType[BasicTrigFunctions][
OOMethodsSin[x_] := Sin[x],
OOMethodsCos[x_] := Cos[x],
OOMethodsTan[x_] := Tan[x],
OOMethodsCot[x_] := Cot[x]
]


Note that the symbols OOMethodsSin etc don't acquire any definitions themselves. Yet, you can create an object of this type and use methods (which are essentially static methods here), e.g. like

obj = BasicTrigFunctions[{}];
obj@OOMethodsSin[x]

(* Sin[x] *)


Now you can, for example, create your own functions as follows:

ClearAll[mySin, myCos, myTan, myCot];
With[{obj =  BasicTrigFunctions[{}]},
mySin[x_] := obj@OOMethodsSin[x];
myCos[x_] := obj@OOMethodsCos[x];
myTan[x_] := obj@OOMethodsTan[x];
myCot[x_] := obj@OOMethodsCot[x];
]


You can check that these functions will work just as well as the original trig.functions we started from, but if the user inspects their definitions, s/he will be stopped at the obj level. Hacking deeper is possible but quite non-trivial, so for non-expert users this kind of obfuscation can be good enough.

Note also, that while right now it is not yet possible, I plan to add the object serializing functionality, so that one would be able to save the created object and then load it back into another Mathematica session without actually loading the OO package. When this is in place, it will make the obfuscation even better, since there won't be a source code available to help with reverse-engineering.

So, as I said: while it won't be particularly hard to reverse-engineer this setup, it should at least help with hiding the definitions from the auto-completion.

-

You can hide it in another context:

xxxContextfooAuxiliary[n_] := (-1)^n*HarmonicNumber[n + 1];
foo[x_] := xxxContextfooAuxiliary[Floor[x]]*Sin[x]

-
Do you mean I am supposed to hope the user doesn't start writing xxx...? –  QuantumDot Jan 25 '13 at 2:30
Yes. In v9 autocompletion shows even Mathematica's own auxiliary functions if user starts typing something like InternalA. –  Nick Stranniy Jan 25 '13 at 2:38
@NickStranniy 3 users (myself included) have voted to undelete your answer, because even though the OP doesn't seem to appreciate it, the answer is valid and a good one and will be helpful to others. This is, in effect, what happens when you use a package and put the definitions in a private context — something I already suggested and was also dismissed by the OP –  rm -rf Jan 25 '13 at 17:40
As I said in my comment to you under the original question, I really didn't mean to put on a negative tone. I was trying to get at the motivation of how your answer works. So sorry! –  QuantumDot Jan 25 '13 at 21:26