Hi Robert.
My preference for this kind of tasks is using objects. Even though it is
a little more verbose, I find it quite intuitive to use the get and set
functions, as in:
>> db: make object! reduce [ to-set-word "first word" 1 to-set-word
"second word" 2 ]
>> probe db
make object! [
first word: 1
second word: 2
]
>> key: to-word "second word"
>> set in db key (get in db key) + 1
>> probe db
make object! [
first word: 1
second word: 3
]
Elan
Brett Handley wrote:
>Hi Robert,
>
>Thanks for the explanation of your reasoning. Looking at the Core guide,
>paths look purpose-built for this sort of database. So your reasons have
>good company :^)
>
>Regards,
>Brett.
>
>
>
>>Hi, there are several reasons:
>>
>>- For storing data I'm always working with nested blocks of name/value
>>pairs. This has proven to be the best approach yet. My goal is to keep
>>this "database" as the master of data, the source. To avoid copying around
>>and to minimize searches in big databases, I always try to work "in place"
>>by using a reference.
>>
>>- Such paths are easy to create programmatically. This code can be used to
>>access/alter record structures in an abstract way, because I can specify
>>parts of a path! (including the last part of a path!) by variables.
>>
>>- I find it logical in the Rebol context.
>>
>>I hope these are good reasons for it :-) Robert
>>
>>
>
>
>
>
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
