Re: hamsterdb Transactional Storage (thanks to all of you)
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 13 Oct 2009 13:48:52 -0300
Message-ID: <4ad4af77$0$23758$9a566e8b_at_news.aliant.net>
>
> ...
>
>
> 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.
Date: Tue, 13 Oct 2009 13:48:52 -0300
Message-ID: <4ad4af77$0$23758$9a566e8b_at_news.aliant.net>
paul c wrote:
> 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.
Sort of a "type sub-language"? ;) Received on Tue Oct 13 2009 - 18:48:52 CEST