Sometimes, in a subnetwork, when you input an object through a null node, you need to know what kind of an object it is. Is it a path or a geometry? Or is it a data table?

Identify takes a single object and returns one of the following identities:

0 - Geometry
1 - Path
2 - Point
3 - Color
4 - String
5 - Integer
6 - Number
7 - Boolean
8 - Data
9 - JavaInteger
10 - Contour (not usable)

You can choose whether to output the name, the ID number (handy for switch nodes), or the Data View. Data View shows you the actual value of the object as it would appear in Data viewing mode. A path appears as < path >, colors as hex codes, numbers and strings as their actual values. The one exception is a data table row which appears as < data >.

The attached demo uses the identify node to display and label thumbnails for each of the first ten data types. (To do this it uses a multi_list node, which I am going to post in the forum right after this. See that post for more details: http://support.nodebox.net/discussions/show-your-work/886-multi-lists).

In creating the identify node I was forced to take a journey into the deepest recesses of Nodebox, and learned many of its quirks and secrets. This includes one data type not handled by identify: arrayLists. The lower right corner of the demo includes a separate network which creates them. More about arrayLists and other peculiarities follows...

NODEBOX PECULIARITIES

There is one type of Nodebox object I purposely chose NOT to identify: arrayLists. ArrayLists are not objects you will normally encounter in Nodebox; they are an underlying data type that can only appear in response to specific lookups.

But even though you can cause them to appear, you should not. They do not provide anything you could not get through other means, and if you attempt to use them you will soon run into trouble. An arrayList presents as a single item, but may unpack its contents if you try to do anything with it. It may claim to be one object but produce multiple outputs when inspected. And the items it outputs may look like normal Nodebox objects, but misbehave downstream. Just say NO to arrayLists!

Following are more arcane details about arrayLists and other Nodebox peculiarities I encountered while making the identity node.

ArrayLists

• I know of three ways to create arrayLists in Nodebox:
  • lookup paths in a geometry
  • lookup contours in a path
  • lookup points in a path
• Each returns a single item in Data view that begins with a square bracket, even if multiple paths or points appear in Viewer view.
• If you lookup class.simpleName on the lookup you will get “ArrayList”.
• Feeding an arrayList into a subnetwork may cause the arrayList to spontaneously unpack:
  • If you feed an arrayList into a subnetwork through a null node with port range set to value, a lookup of class.simpleName will show path, contour, or point - but it will return that name once for each item in the arrayList, despite only firing once.
  • If you feed an arrayList into a subnetwork through a null node with port range set to list, a lookup of class.simpleName for contour and path arrayLists will return a single value “ArrayList”. The same network given a points arrayList will return “point” multiple times; this is a consequence of the points and null behavior (see below).
• In order to ensure that an identity check always returns a single value, I pass the input through a first node. When asked to identify an arrayList the node will identify the first item in that arrayList.
• It is possible to force the the lookups of paths and contours to return items instead of an arrayList by opening the lookup node with the Metadata dialog, look under NODE/Settings, and change Output Range from list to value. You can achieve the same thing by passing an arrayList through my fix_arrayList node (which is simply a null node wrapped in a subnetwork).

Java Integers

• Certain lookups (e.g. type for points and pointCount for paths) will produce an output that looks like an integer but is actually a Java Integer.
• If you do a class.simpleName lookup on a Java Integer, it will return “Integer”. Confusingly, if you do the same lookup on a normal Nodebox integer, it will return “Long”. My identify nodes show Longs as Integers, and Integers as JavaIntegers.
• A JavaInteger will cause errors if you try to do calculations with it or even convert it to a string. To use a JavaInteger you must first clean it by passing it through an integer node.

Contours

• Contour objects can only be produced in Nodebox through the lookup contours. They will look like paths in Viewer view, but will cause errors if you attempt to colorize them or treat them like normal paths.
• In order to separate a path into useful contours, use my contours node. This node returns contours as ordinary paths.

Data Tables

• My identify nodes treat data tables as another class, like points or strings. But in fact they are not a class.
• When you apply a Keys node to a data table, you get the column names of that table, not object properties. And if you lookup class.simpleName for a data table, the lookup fails and you get no response at all (which can cause havoc downstream).
• Special handling was required to identify data tables as named objects on par with other objects.
• If you set Output to Data View, my Identify node will display items as strings the same way they would appear in Data view - except for data tables.
• In Data view, data tables are displayed as full tables with column headers with color banding for the rows. This would be inconsistent with the output for other objects, so instead my Identify nodes display each row of data simply as “Data” inside angle brackets.

Points and Null

• The null node treats points differently than other Nodebox objects.
• If you make a subnetwork consisting of a null node - published with range set to value - connected to a rendered count node, that subnetwork will fire once for each item fed to it and output a 1 each time - with one exception.
• If you feed this same subnetwork a list of, say, six points, you will get a single output of 6. Despite setting range to value, the subnetwork will input the points as a single list.
• If you repeat this experiment using a subnetwork with a point node as input instead of a null node, the same list of six points will return six 1s.