"Hey Caden, I've written a FeatureScript, and I want to share the feature, but not my source code. Is there any way to do that?" - Anonymous
This is an interesting, but common challenge. Unlike compiled programs, FeatureScript code is usually right there in the open, and easily copied. But never fear, there is a solution.
The answer, is layered features. Follow along with this sample document.
The first step, is to write a feature like normal. The key difference here is that we are going to write the entire feature inside of another function instead of the main body of the feature. Our feature body for testing will just reference this main function.
The predicate is our input (feature UI), and our main function contains the body of our feature. Both of these need to be exported to make them available in the public feature.
Now, the Enum parameter poses a problem. Enums need to be exported from the public feature, so we have to put the enum declaration in its own feature studio. All of the code in the enum's studio will be exposed and made public, but that is fine, because an enum isn't really secret information.
Finally, we make a new document, and create a feature that imports our source code. Its important to note here that the source code is imported, but not exported! This prevents the code from being used by other users. The source code can remain a private document, while this public feature can be shared with anyone.
Its important to note that the example document has all three tabs in the same document. The private source and enum code should be in a separate private document, and only the public feature in the public document.
But how does this keep someone from stealing my feature? Can they not just import the code?
Onshape does not allow someone to copy that import line into their document if they don't have permission to the inner document. Its counterintuitive coming from other programming languages, but Onshape has woven a bit of magic into FeatureScript that lets this happen.
Are there other uses for this technique?
Yes! For companies doing large feature releases, this can also be used to do "development" and "production" releases. The import statement references a specific version of the source code. You can update the source code of the development feature without affecting the production version. When it comes time to update production, just update the import statement to the stable development version.
Comments