Passing in featureList as Argument, but not from a Feature Parameter

Jonathan_Hutchinson

I'm in a slight dead end figuring out how a feature I've written can be used by some other features, when the feature has an 'is featureList' input (to ingest all the things created by a feature, which may vary).

See the below example, where I want the thing represented by 'fList' to be a featureList type, and for it to contain the things created by id + "patternDivided". I don't quite understand how to pass something to the featureList function that will yield something of type feature list, and so get a precondition fail of 'is featureList'. I suspect, though, that I'm maybe abusing the featureList type here.

        opPattern(context, id + "patternDivided", {
                    "entities" : qCreatedBy(id + "divideEntities", EntityType.BODY),
                    "transforms" : transforms,
                    "instanceNames" : instanceNames
                });

        var fList;
        fToCall(context, id, { "feat" : fList });<br>

Alex_Kempen

The FeatureScript std has many functions which are intended primarily to be internal-only functions. As a result, these functions often have little to no documentation. In cases like that, it's best to check the source code directly. Here's the source for featureList:
https://cad.onshape.com/documents/12312312345abcabcabcdeff/w/a855e4161c814f2e9ab3698a/e/532a337c28a6fe5a6eacd744

Looking at the code, a FeatureList type is simply a mapping of ids to functions. From applyPattern, it appears that these functions take a single argument, an id, and execute the corresponding feature. The ids are the featureIds of a given feature in the list. The valuesSortedById function sorts the map into an array of functions as determined by the order of ids in the feature list, which makes sense since maps have an arbitrary internal ordering (usually alphabetical), and you logically need the feature list to be in order so they execute properly.

Based on the above, it appears that the featureList type is not generally suitable for use in FeatureScripts outside of a FeatureList parameter. To my knowledge, there is no way to access other feature functions in the feature tree from another FeatureScript (short of using a FeatureList parameter, of course), nor is there any way to generate them at runtime, since a feature really needs a definition specified in the feature tree to be useful.

As an alternative, I would recommend writing a lower level function inside fToCall which takes a query instead of a feature list (If you're into software design, this is a good example of dependency injection). This implementation is very similar to how Onshape is designed with high level functions (features) as well as the low level operations for said features (the op functions) - although you could call the high level functions directly, it's oftentimes much easier to call the low level operations directly.

If you were to implement this, your fToCall function could become a trivial wrapper which converts the FeatureList into a qUnion of qCreatedBy calls before calling the inner function. I don't believe you were actually calling the features anyways, so you shouldn't have issues with no longer being able to tweak the behavior of each function before you execute them. Because of this, you also shouldn't have to worry about order, but if it was relevant then you could always take advantage of valuesSortedById to get a list of ids in evaluation order (you could remap your FeatureList to a mapping of ids to qCreatedBy calls, for example).

Hopefully some of that makes sense - let me know if you want any additional clarification.