[REBOL] Re: Profiling Rebol API to DyBASE
From: robert:muench:robertmuench at: 21-Dec-2003 14:41
On Sat, 20 Dec 2003 21:16:01 +0300, Konstantin Knizhnik
<[knizhnik--garret--ru]> wrote:
> I thought, that once objet is created using prototype object, the
> values of prototype object fields are just copied to the new objects
> (doesn't matter whether them are scalars, series or functions).
> In this case there will be only one instance of the function compiled
> and bounded only once. But looks like it is not the case.
Hi, that's the difference in Rebol. It's not an OO language and it's
object! datatype isn't OO related. Every word carries its own context.
That's why you get the same words bound to different (new) contexts each
time. The solution is to move the functions out of the context.
> Rebol objects fits in this model (the only problem is that there are
> no classes, so I will have to make programmer to specify prototype
> object for the class). But if we provide persistency not for objects,
> but for blocks, then it is not clear to me how to store them.
> There will be no field names (but will be "hidden" fields, like
> current position name in variables referencing series).
Here is a rough sketch of an idea:
A database could look like this:
mydb: [ data [...] indices [...] db-meta-data [...]]
Making blocks persisten will add an OID and a block reference to mybd/data
as name/value pairs
mydb: [ data [OID1 mydata1] ...]
To index data there are serveral ways: 1) let the programmer add the
fileds and the DB only maintains the mapping value/OID or 2) I'm
registering which fields should be indexed.
mydb: [ to-index [name street city ...] ...]
The make-persisten function will look into mydb/to-index and check if the
block-to-be-made-persisten contains any of the listed fields. If so it
takes the value and the new OID and build the index.
IMO the Rebol way to persistence is to dissolve that we need a fixed
object structure. What we need is a lookup mechanism to answer things
like: Give me all blocks that contain a 'name field that has a value in
the range from A to B. What kind of blocks the result will be doesn't
matter to the DB. The programmer needs to be aware to structure this.
For example: I can add an internal field to my blocks to specify a class.
What I'm going to do with this information is up to me and my program.
mydata1: [_class address/germany name "" street "" city "" zip ""]
mydata2: [_class address/usa ...]
Both can have different field sets but the overall semantics is an
'address to my program.
I hope you got the idea.
> So it is possible to write normal serialization mechanism for Rebol
> (one that will preserve relations between objects), and even create
> database, which allows not only load/store, but also change/retrieve
> the data.
That sounds good to me! It should (in the first run) only be a persistent
storage.
> But it could not be done within DyBASE object model.
That's a pitty. I looked at DyBASE because it's intended for scripting
lanugages and I though maybe it fits the Rebol world.
> First task is significantly simpler, and if such module will be really
> interesting to many Rebol users, I can try to develop one.
I vote for it! We than can see how far we can go and what features need to
be added to the persistens engine or to the Rebol code side. What do you
think?
--
Robert M. Münch
Management & IT Freelancer
Mobile: +49 (177) 245 2802
http://www.robertmuench.de
