[REBOL] Re: Profiling Rebol API to DyBASE
From: knizhnik:garret:ru at: 22-Dec-2003 0:32
I have released new version of DyBASE (0.16 ).
Graham Chiu implemented in Rebol program which used DyBASE to store
extracted mails from the server. It detects one problem in DyBASE related with storing
strings. That is why I have to release new version.
It also includes new version of Rebol API:
- generic index factory implemented by Gregg Irwin
- I made all methods from persistent external functions. So now nstead
of doing "obj/modify" you should use "modify obj". The name of all
methods is preserved, except "load" method which is removed to
(to avoid conflict with system function).
I hope that other methods (store, modify, deallocate,...) will not
cause conflicts. In future if Rebol will provide efficient
mechanism for methods, I return these methods back to persistent
class. And right now it allows to reduce overhead of object
prototyping and save a lot of memory. Now it is programmers choice
whether to use object methods, external functions or use special class
with method definitions.
Also I have updated comparison table using as reference system my home
computer. Result are different but in general ration of performance of
different languages is the same.
Sunday, December 21, 2003, 4:41:53 PM, you wrote:
RMM> On Sat, 20 Dec 2003 21:16:01 +0300, Konstantin Knizhnik
RMM> <[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.
RMM> Hi, that's the difference in Rebol. It's not an OO language and it's
RMM> object! datatype isn't OO related. Every word carries its own context.
RMM> That's why you get the same words bound to different (new) contexts each
RMM> 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).
RMM> Here is a rough sketch of an idea:
RMM> A database could look like this:
RMM> mydb: [ data [...] indices [...] db-meta-data [...]]
RMM> Making blocks persisten will add an OID and a block reference to mybd/data
RMM> as name/value pairs
RMM> mydb: [ data [OID1 mydata1] ...]
RMM> To index data there are serveral ways: 1) let the programmer add the
RMM> fileds and the DB only maintains the mapping value/OID or 2) I'm
RMM> registering which fields should be indexed.
RMM> mydb: [ to-index [name street city ...] ...]
RMM> The make-persisten function will look into mydb/to-index and check if the
RMM> block-to-be-made-persisten contains any of the listed fields. If so it
RMM> takes the value and the new OID and build the index.
RMM> IMO the Rebol way to persistence is to dissolve that we need a fixed
RMM> object structure. What we need is a lookup mechanism to answer things
RMM> like: Give me all blocks that contain a 'name field that has a value in
RMM> the range from A to B. What kind of blocks the result will be doesn't
RMM> matter to the DB. The programmer needs to be aware to structure this.
RMM> For example: I can add an internal field to my blocks to specify a class.
RMM> What I'm going to do with this information is up to me and my program.
RMM> mydata1: [_class address/germany name "" street "" city "" zip ""]
RMM> mydata2: [_class address/usa ...]
RMM> Both can have different field sets but the overall semantics is an
RMM> 'address to my program.
RMM> 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.
RMM> That sounds good to me! It should (in the first run) only be a persistent
>> But it could not be done within DyBASE object model.
RMM> That's a pitty. I looked at DyBASE because it's intended for scripting
RMM> 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.
RMM> I vote for it! We than can see how far we can go and what features need to
RMM> be added to the persistens engine or to the Rebol code side. What do you
RMM> Robert M. Münch
RMM> Management & IT Freelancer
RMM> Mobile: +49 (177) 245 2802