Re: hamsterdb Transactional Storage (thanks to all of you)

From: paul c <toledobythesea_at_oohay.ac>
Date: Tue, 13 Oct 2009 15:57:03 GMT
Message-ID: <jr1Bm.48672$PH1.39852_at_edtnps82>


Bob Badour wrote:
> paul c wrote:
>

>> Bob Badour wrote:
>>
>>> compdb_at_hotmail.com wrote:

...
>> And what "detritus" is avoided?

>
> What detritus or "features" do we have now that one could more
> accurately and more robustly model with user-defined types and type
> generators?

Thanks, I see it was about user-defined types all along. Call me a language philistine, I've always been unhappy about integrated user type support because I think that makes user languages more unwieldy than they need to be, way too much so. In the old days, most customization of that sort was labelled "exits", in the late 1970's people started calling the same thing "drivers". Today I don't know what products, if any, support an add-on layer and probably the only "exit" most people are aware of are simple functions to handle sort comparisons. I've never seen much advantage in having dynamic binding for type operators and there is huge practical work to make sure a type isn't redefined in a way that distorts the original data. Maybe if the big-name products had had a way of linking type "drivers" from day one we'd now have a viable and competitive sub-industry supplying alternative types that users could choose from. 'Lord knows there are plenty of encoding standards. Personally I think it better to apply type theory in a separate implementation language which most users could ignore and which wouldn't need to be optimized by the dynamic engine. Received on Tue Oct 13 2009 - 17:57:03 CEST

Original text of this message