So a few weeks passed and we had time to check details on new data types. Years ago I appreciated books like Inside Turbo Pascal (or similar name) which explained all the details behind the runtime, compiler and data structures used there. Sometimes I'd wish someone knowing internals would document them in nice articles to give us interesting knowledge. Especially sometimes you can write better code or optimize for performance if you know how things work internally. Until that, here are my observations on the new data types:
The new text data type is interesting. The idea is to have a data type for a string of unicode characters is good and removes a couple of downsides on the old string data types. We have a lot of fallback code in MBS plugins to handle things right. For example the plugin will default to some text encoding if you pass in a string with no text encoding. On the other side we still need to put JPEG data into string to write them into a binarystream object. In the last months I moved a couple of methods to use Memoryblocks for a block of bytes instead of a string, but that causes a lot of unnecessary automatic conversion.
The new text data type is not a normal class, so you can't assign it simply to object variable. But it is reference counted like the old string class and any objects in Xojo, so memory storage is efficient. Especially as text is either stored in ASCII or Unicode internally depending of content. Most texts for us western people is just ASCII, but anything containing umlauts or the asian characters will be stored as UTF16. And it looks like UTF16 is converted to Normalization Form Canonical Composition. The ä (umlaut a) for example is stored as one unicode character and not as two like Mac OS X does it for file names.
The new auto data type is similar to variant. It wraps the data type, but does not do the auto conversion. So assigning an auto value with text inside to an integer will give a TypeMismatchException. This data type is also not a regular object internally (can't be assigned to object variable), but it is reference counted. At least passing an auto value around seems not to copy it.
But something is strange there. Auto seems only to be a number internally, maybe a key in a dictionary the runtime manages? Or a structure based data type? Well, we have to wait for Xojo Inc. to explain some of the internals, so we can make better use of the auto objects.
To know type of data in auto, you can use the new framework's introspection functions:
dim a as auto = 123
Dim info As Xojo.Introspection.TypeInfo = Xojo.Introspection.GetType(a)
which gives you text "Int32" here. Please note that older introspection functions like Introspection.GetType do not work on auto data type.
While you can't assign nil to a text, you can do so to auto. And auto can be compared with nil, which is also the default value. And is actual integer/pointer value of auto in that case is indeed zero (you see that if you debug a plugin function taking auto parameter). Vartype function seems to work on auto data type just fine, but that may be just due to the unpacking and repacking as variant.
When you stuff text in a variant, you get a new variant type with number 37 internally. At least vartype() returns this number now for a text variant. To get back the text from the variant, you can use TextValue function. Or use StringValue which converts to normal string. For array of text, well this will gives vartype 4096 + 37.
For auto data type, we can note that if you put an auto into a variant, it's unpacked first and the data type itself is wrapped for the variant. So putting auto with text into variant, gives you a variant of type text.
For the plugin we created a couple of feedback cases to allow text (37329) and auto (37330) data types. Until we have some API, we ignore them in general. For variants we treat them as strings and use StringValue property. Arrays of text can be passed to plugin inside a variant, but the plugin can only ignore them currently.