In KB entry P133247 the question is raised as to whether ABL has the functionality to convert a string to an object reference.
This could refer to whether or not there was a object form of string in the sense that Java has both primitive and object forms of all basics like string and integer, but I am guessing that is not what it refers to since it would then have been much clearer to refer to all types.
Rather, I would guess that it refers to Object -> String -> Object conversions ... and, of course, it would be a better KB entry if it referred clearly to the whole cycle.
While it is true that there is no construct of the form
ObjectVariable = object(StringVariable,"ObjectType")
there are two missed opportunities here.
First, what one really wants, if an enhancement is to be made, is an extension of the WRITE-XML() and READ-XML methods that exist for temp-tables and PDS to apply to objects as well. It would be helpful to guide the enhancement requests in that direction and I would suggest it should go so far as to point to an existing ERS entry.
But, to be more helpful, it should also be pointed out that creating one's own Stringify() method for an object which produces an XML string containing the values of the object is quite easy and, having done so, it is then also very easy to overload the constructor such that a NEW with no arguments creates an empty object, but an argument with a string argument, unpacks the XML in that string to create a fully populated object.
Object to XML serialization and deserialization are not the only use cases for the (missing) string to object conversion.
I guess, I'm not the only one who is used to comma delimited lists of widget handles (ADM2 style, I know). This would be a light-weight replacement for the missing features of lists or collections.
I've solved this in my class framework in a common base class for all other classes. In the constructor I do create a GUID value for each instance and "register" that in a manager class using a static method. I've overridden the ToString() method to return the GUID aka handle to the class. This let's me use STRING(objvar) similar to STRING(widgethandlevar).
To get the object reference from the GUID, I use another static method of the manager class (ClassHandle). This uses a lookup in a temp-table used inside the manager class and returns a reference to the instance. I have customized methods to return typed references as well.
Having this feature out of the box as the default STRING to Object conversion would feel more natural to me than XML deserialization - as this would be consistent with how widget handles are used in the ABL.
I'd love to have XML serialization out of the box, but as the source "string" could come from a DB/temp-table field, mempointer, longchar or string I'd prefer READ-XML and WRITE-XML methods (overridable) similar to ProDatasets.
I guess I'm not seeing that there is any conversion going on in what you discuss. It seems more like lookup. I can think of several ways that one could implement having a pool of objects which remain instantiated and then finds and uses them in a new context, but there isn't really any serialization or conversion going on there. This seems to me just having some kind of unique reference by which one can find a specific object reference. Depending on context, one might want to find a specific object, any object of a particular type, or the object, i.e., a singleton and each need has its own techiques ... but in none of them is the object itself ever anything except an object.
Objects can have pretty complex sets of data members, so I don't see how one could do meaningful serialization with anything less than XML .... well, or something proprietary, but that is less interesting.
It's the same sort of cenversion between widget handle and string and string and widget handle. With the difference that it can be typed.
OK, but still it seems to me a class of problem which is best solved by a manager, as you have done. I can't get very excited about merely being able to get a string for an object handle.
Of course, the KB entry could be enhanced by discussing that too.