Overview:
The purpose of this article is to explain the changes being made to the nTop type system.
Table of Contents
1. Effective Release
2. Change
3. Why is this change happening?
4. Major Changes
4.1. List Processing
4.2. Groups
4.3. List Interface List
4.4. Property Usage of Abstract Types
4.5. Interface Functions
4.5.1. Using Interface Functions as Inputs
5. How does this affect you?
1. Effective Release
- nTop 4.1
2. Change
- In nTop 4.1, we are releasing improvements to the nTop visual programming language that involves migrating our type system. We will now support two type systems: pre-4.1 (old) and post-4.1 (new).
- In the new system, behaviors will be changing when working with:
- Lists
- Groups
- Abstract Types (e.g., Material, Spatial3D)
- Interface Functions (e.g., Translate Object, Rotate Object)
- We fully maintained backward compatibility with this type migration so any previous notebooks can be opened, viewed, run, and edited in nTop 4.1+ and future versions.
3. Why is this change happening?
In the past, nTop had made decisions to help ease the usability of complex types. Over time, the usability benefits became significantly outweighed by the unsafe type behavior that arose, causing bugs, undesired behaviors, and limitations to the nTop programming language.
With the release of nTop 4.1, we want to ensure that the nTop programming language can grow in a scalable manner to enable more powerful and robust computational design workflows in the future so that you can build the best parts.
4. Major Changes
Any new notebooks and most (>95%) of existing notebooks will be moved into a new type system with the new behaviors.
A small percentage of existing notebooks (<5%) with type artifacts will stay in the old type system and will not have these new behaviors. Over time, we will migrate these notebooks to the new system once we can maintain backward compatibility. The behaviors for the new type system are detailed below.
4.1 List Processing
4.1.1. List Processed Output
If a block “list processes,” nTop would previously not correctly mark the output as a list until the block ran. Now it will do so as soon as it has enough information to know that the block will “list process.”
For example, in the old type system, Mesh from Implicit Body (shown below on the left) would not convert to a "Mesh List" type until it was run. In the new type system (shown below on the right), Mesh from Implicit Body is converted to a "Mesh List" type as soon as the Box List is placed into the Body input.
4.1.2. Non-List Variables
The new system will treat variables you declare as having real intent and respecting the type they are declared as. It will no longer be possible to use lists in certain situations, notably as primary inputs for variables of the non-list type.
For example, in the old system, non-List Variables could receive List blocks as a primary input but would throw an error once the block was run (shown below on the left). To help reduce confusion and errors, in the new system, non-List Variables can no longer receive List blocks as a primary input (shown below on the right).
In the new system, to place the Mesh List variable in the Volume Mesh variable, you must change the Volume Mesh type to a "Volume Mesh List" via the type dropdown in the top left of the block (shown below).
4.2. Groups
When accessing Group elements, List Element will no longer automatically convert from "Any" to the appropriate type in the new system. See the below example of the old system (left) and new system (right).
To access Group elements, you now follow similar principles as Non-List Variables. First, declare the List Element a variable. Then, express your design intent by specifying the type of the Group element you need to access via the type dropdown (shown below).
This same procedure can be followed to convert a Custom Block that leverages a Group and returns an "Any" type into an appropriate type - the best example being the "If" Custom Block (shown below).
4.3. List Interface List
When using List Interface List, you can no longer access the list element variable as one of those specific types from the properties panel. In this case, list elements dragged out into the notebook can only be used via functionality common to all list possibilities. Below is an example of the old type system (left) and new type system (right) behavior. If you need to access a more specific type, we recommend changing the type to an "Implicit Body List" or using a Group instead.
4.4. Property Usage of Abstract Types
When a variable can hold objects of different types, an abstract type such as a “Material” or “Spatial3D”, it will no longer be possible to use that variable as one of those specific types; it can only be used via the functionality common to all possibilities. This will allow users to change the type held in that variable without breaking the downstream workflow.
Below is an example of what this looks like in the old system (shown below on the left) and the new system (shown below on the right). You will no longer be able to reference properties for abstract types like “Material.” If you need to reference their properties, change it to a concrete type using the type dropdown at the block's top left.
4.5. Interface Functions
Interface Functions can take multiple types and output the same type as the primary input (shown below).
The complete list of Interface Functions are:
- Concatenate Lists
- Filter
- Insert
- List Element
- Orient Object
- Remove
- Rotate Object
- Scale Object
- Select by Choice
- Sort
- Sub List
- Transform Object
- Translate Object
4.5.1. Using Interface Functions as Inputs
When using an interface type in a block input, it will convert to the appropriate type. Below is an example of this in the old system (left) and the new system (right). In the new system, the Translate Object is converted from a "Spatial3d" type to a "Point" type.
4.5.2. Interface Types
An interface function will convert to the appropriate type as soon as it knows the primary input type, even if other inputs have not been populated. Below is an example of this in the old system (left) and the new system (right). The new system converts the Translate Object from a "Spatial3D" type to a "Box List" type before the block is built.
5. How does this affect you?
As previously stated, we fully maintained backward compatibility so any previous notebooks can be opened, viewed, run, and edited in nTop 4.1+ and future versions. In notebooks in the new type system, there will be behavior changes detailed below.
Primary
When working with list-processed blocks, there will be limitations to making sure your notebook complies with type safety (see List Processing). This will prevent you from dragging and dropping list blocks into non-list variables and limiting your options when using Context Search on list-processed variables. These limitations do not apply when dragging and dropping list blocks into non-variable list-processed blocks.
Secondary
When accessing List Elements from Groups or when using Custom Blocks that contain Groups and return "Any", you will need to manually declare them variables and change them to the appropriate type (see Groups).
Tertiary
If you work in notebooks with the old type system, you can continue to perform all editing functionality with one exception. The only editing limitation you may encounter is being prevented from copying and pasting blocks or collections of blocks containing type artifacts. This is done to prevent type artifacts from notebooks in the old type system from being copied and pasted into notebooks in the new type system. In the unlikely event this does happen, you can still use the Duplicate command to copy these blocks within your current notebook.
The other three areas (see List Interface List, Property Usage of Abstract Types, and Interface Functions) should be minor differences when editing notebooks in the new type system.
If you have any questions, please reach out to nTop Product Support at support@ntop.com.