Re: [tutoriald-design] D over an existing language?

[<reh...@t-...>]

Hello,

On Sat, 2 Aug 2003, Brian Olsen wrote:

[...]
>
> 	After reading a bit of C.J. Date's books (the manifesto, intro), I've
> been pondering how a D-type language would fit into a existing
> language. I see that there is the Duro library, but alas, I don't know
> C to grok it (going back to school to learn it though. :-) I am
> specifically interested in (even though not completely committed to,
> yet) implementing a relational library in Python (because it is my
> favorite language. :-)
>
> 	I think the most interesting things that can arise from such a library
> is:
> 		- the ability to create data types of arbitrary complexity (maybe
> through classes?

The problem of implementing user-defined types using Python is that, to my
knowledge, Python is one of the languages that belong to the 'object
world', which is, sadly, incompatible with D in many respects.

These languages, for example, are heavily using references, which are not
allowed in a Database in D. This has important consequences for
user-defined types.

For example, read the discussion about the difference between D
selectors and object world constructors at the end of the informal
discussion of RM prescripion 4 in chapter 6 of the TTM.
You must be aware of these problems if you try to implement D using an OO
language like Python.

By the way, the next version of Duro (0.6) will contain support (although
still limited) for user-defined types, TTM style. That support is already
in the CVS.

> 		- the ability to define relations via a DDL that enforces such things
> as the primary key requirement.
> 		- the ability to use the same "query language" within an application
> seamlessly as well as used in an ad-hoc query tool
> 		- portability - I would start on Berkeley DB (like Duro), but make it
> portable, especially in case a true relational database engine comes out

Well, I am not sure what would be gained by starting to implement a D
system in Python using Berkeley DB, because that would very much repeat
the work which was already done (or will be done) to implement Duro. I
don't think the possibility to use the Berkeley DB Python API compensates
for this.

As Leandro suggested, it may be a better idea to write a Python interface
for Duro. This would have to be done in C, but would be much less work.

--
Rene´ Hartmann