On Thursday, 23 May, 2019 14:39, Jens Alfke <j...@mooseyard.com> wrote:
>> On May 22, 2019, at 8:16 PM, Keith Medcalf <kmedc...@dessus.com> >wrote: >> Basically, User Defined Types (UDT) were implemented in a fashion >analgous to a C++ class (remember that at this time C++ was just a >pre-processor for C and a C++ class was nothing more than a struct >and mangled function names to operate on the class). >…and a vtable to provide polymorphic dispatch of virtual methods, >which is required for OOP. >> Basically, when you declared something as a UDT you were giving a >"blob" a type-domain. Whenever you tried to do something with a UDT >a "mangled function name" was generated that took that blob as the >first argument >Was DB2 using early or late binding of types to blobs? That is, was >the type of a blob declared as part of the table column, or were >individual blob values tagged with their own types? This makes a huge >difference. In the former (early) case the UDTs are just syntactic >sugar, while with late-binding they really do act like objects. Late- >binding is also required if user-defined functions are to be allowed >to return UDTs. The initial version was entirely early binding via column declarations of the type, so they were syntactic sugar, not real polymorphic objects (in the sense of how real objects and types work). Now I believe you can implement UDT's as true objects (but still early bound via the column declaration) as C++ or Java or whatever classes. It was a long time ago and I haven't touched DB2 for a long time ... I only remember because at the time I was doing Level 2.5 support for the IBM CSet++ Compiler package at TOROLAB6 and we had lots of interaction with the DB2 developers who were just up the road >> you merely implemented a bunch of functions with the appropriate >names that DB2 would use whenever you referred to that UDT type, >rather than using the builtin functions (this is similar to the way >languages like Python implement classes). >Not really; in Python (and Ruby, and Objective-C, and Smalltalk, and >sort-of JavaScript…) a class is a dictionary that maps method names >to anonymous functions. The functions themselves don't have names. >(Sorry to be pedantic, but I'm a bit of a language geek.) No need, but you are correct. I believe that in fact the implementation that was released was based on proper dictionary based method dispatch and that all the other "standard internal types" ended up being implemented in the same fashion (just with standardized builtin models). That is, even a standard "varchar(20)" or "integer" or "decimal(10,4)" was nothing more than a binary blob in the database that had a builtin method dictionary attached via the declaration. The nice part was that the system implementation was extensible by being able to provide your own binding dictionaries, and that everything, whether an "internal" or UDT was implemented using the same methods. I don't know if the types were ever actually polymorphic or supported multiple inheritance or not. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
