Re: Introducing PlayDB (The Model, The Language, The DBMS)

Hi,

I would like to know how you generate those introductory phrases attached to your quotations of other people!

Christopher Browne <cbbrowne_at_acm.org> wrote in message news:<bm9si2$k6t77$2_at_ID-125932.news.uni-berlin.de>...
> In an attempt to throw the authorities off his trail, seunosewa_at_inaira.com (Seun Osewa) transmitted:
> > "Bob Badour" <bbadour_at_golden.net> wrote:
I did not mean to imply that Bob Badour mentioned Self. It turns out that Self is not what I thought it would be while leaving for the night. Don't you see the potential calue of allowing objects to join and leave classes as necessary over time? It is all about letting data last long even if its accessed differently. "Large Shared Data Banks" anyone?

> > SELF is a classless programming Language, claims to be object oriented
[snip]
> SELF isn't "typeless;" the only language I recall that _claimed_ to be
> such was BCPL (predecessor to B and C), and even there, that wasn't
> honestly typeless; it was instead pretty "loose" about them.
>
> Perl and TCL both have a history of pretending "typelessness;" their
> scalars can be coerced into pretending that they are strings or
> numbers depending on what operation you use on them. Mind you, since
> they have aggregate 'types' it's again not honest to call them
> "typeless;" they are more 'schizophrenic about types.' (Which is
> sometimes a big pain.)
>
> What could be of _some_ merit would be to have a system that is 'type
> agnostic;' that is, you have containers/slots in which you can put any
> type. That's sort of what Self does; that's _certainly_
> characteristic of the Lisp family. The latter is strongly typed, but
> common data structures allow plunking in data of any type, in contrast
> with (say) ML.

What I am really trying to say is, if a single object can present itself as a member of any class to which it is supposed to belong, and we use special constraints to model other concepts like type inheritance, the system would be interesting and very flexible. If an circle can wake up and say, "ok I am changing my dimensions I am no longer a circle". if the DBA can say "all right employees no longer have to be managers". Will get back to it. I have done little frther development of the ideas.

> Whether or not this is any good for databases is another question. The
> _problem_ with being open to a "loose" set of types is that there then
> needs to be code to interpret the different types.

Interesting food for thought. In other words, implemention difficulties. Its notable that a special index structure would have to be created just to be able to tell what objects in a system belong to a particular class. It'll no longer be as simple as a sequential scan on a file. So its good to be able to rearrange the objects based on read patterns and that's where log-structured data storage might be useful.

But at the right stage I would investigate to see if by taking advantage flexibility of the scheme we can in some cases buy back some of the lost performance. And make programs simpler. But meanwhile maybe I should work on the object model? I do not yet se how to link this with the idea that the database is essentially a colection of assertions unless I say a collection of assertions about the existence of an object with certain properties. Seems like a restriction in the general case which means the relational model may be even more of a restriction.

Best Regards,

Seun Osewa. Received on Mon Oct 13 2003 - 02:45:40 CEST