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

From: Bob Badour <>
Date: Tue, 13 Oct 2009 13:48:52 -0300
Message-ID: <4ad4af77$0$23758$>

paul c wrote:

> Bob Badour wrote:

>> paul c wrote:
>>> Bob Badour wrote:
>>>> 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.

Sort of a "type sub-language"? ;) Received on Tue Oct 13 2009 - 18:48:52 CEST

Original text of this message