Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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