World: r3wp

You cant extend objects in place. sadly. Carl says its only a little 
change in the code, but is unsure if it is a good idea. switch to 
blocks or keep the objects in a hashtable and reference them by name. 
Or use a mix, some fixed fields and a block for the extensible part.

crap... oh well


anton, W is really a big object block with many nested objects. I'm 
building a list of relations, so I can relate words and numbers to 
eachother in a database

can't you use the object as a template to create a new object with 
the new field and then copy it back again?

Well, that's what I do when I need to extend an object .. though 
it's not in place.

the point is, I need the position to copy it into. The position is 
automatically and elegantly referenced by Y and can be a lengthy 
calculation, if I need to find it again, but I may need to do that 
or make some other position marker which contains the block that 
holds the object I need to change.

You could do it indirectly. 
obj: reduce[make my-object]
and always access with obj/1 .
then extending with 
  obj/1: make obj/1
not really nice too. We write a RAMBO-request?

volker, that doesn't work here? I lose the reference immediately 
when doing obj/1: make obj/1

its not my typo? must be with block,
obj/1: make obj/1[]

i test it.

I anticipated that

thought so. was to easy :)

!>>obj: reduce[context[a: 1]]
== [make object! [
        a: 1
    ]]
!>>obj/1: make obj/1[b: 2]
!>>probe obj/1
make object! [
    a: 1
    b: 2
]

But the obj/1 must be on every access, and bindings are still lost.

yes....

>> w: reduce [[test 1][test 2]]
== [[test 1] [test 2]]
>> set [y] w
== [[test 1] [test 2]]
>> y
== [test 1]
>> y/test
== 1
>> y/test: 100
== 100
>> w
== [[test 100] [test 2]]

>> c: context [test: none]
>> b: reduce [in c 'test]
== [test]
>> reduce b
== [none]
>> c: context [test: 1]
>> b: reduce [in c 'test]
== [test]
>> reduce b
== [1]
>> c: context [test: 2]
>> b2: reduce [in c 'test]
== [test]
>> reduce b2
== [2]
>> b
== [test]
>> reduce b
== [1]
>> reduce b2
== [2]

The first of the two examples above shows how to use path notation 
to select and change values in a block.

The second of the two examples above shows how to use a "throwaway" 
context to store new words in, then to reference these words from 
inside a block.
Both examples are showing how to use blocks instead of objects.

One of the advantages of objects is the convenient path syntax to 
get to a value. Hopefully, the above examples show how this can be 
done with blocks.

anton, that's very interesting. a shame that I'm almost done now, 
still a few bugs left. :-) I solved the problem by going one step 
backwards. it happens to be that all objects are stored in a block 
so I can change it on the spot that way. the trick was to figure 
out how to move backwards and get the rules right.

What does your system look like now ?

entangled in lots of debug code :-)

I mean .. the essence of it .. :)

well, I use a structure like this:

<word>: [
  <id> make object! [
    <word2>: [
      <id2> make object! [
        <word3>: [<id4> <id5>]
      ]
      <id3> make object! [
        <word4>: [
          <id6> make object! [
            <word5>: [<id7>]
          ]
        ]
      ]
      <id4> make object! [
        <word6>: [<id8> <id9>]
      ]
    ]
  ]
]

a word relates to one or more values which relate to more words which 
can relate to more values

So it works ok ?

then I have a function that asks for a specific relation by diving 
down a path with a block like: [customers 1234 invoices 45 articles 
15] to find customer 1234 who has invoice 45 which holds article 
15

then there is a function to add and remove relations

there are a few bugs left, but they are easy to fix

That's good. So you managed to stick with objects somehow, anyway.

Oh I see of course.

most bugs seem to be fixed now. I made a little release on http://www.hmkdesign.dk/rebol/

the question is whether this is useful to anyone :-)

See how it performs for a little while, first... :-)

this might be something dangerous:

write %test.r "hello"
path: what-dir
remove back tail path
write %test.r "hello" ; this fails


problem is: what-dir returns directly system/script/path what seams 
to be used in order to resolve relative file values

I just recognized it using the request-dir from didec which was in 
the rebgui distro -038 (he's doing this in the request-dir function 
in the line with


if all [not empty? path slash = last path][remove back tail path] 


so question is whether this is a bug and belongs to rambo, is ok 
(I don't think so) or what else ?

might also be that didec changed this in a later version (script 
was dated 2003 and maybe at this time 'what-dir had a different behavior), 
but this doesn't matter regarding what 'what-dir returns

dangerous in the sense hard to get why suddenly some 'write doesn't 
work anymore

its another form of change-dir IMHO

So there is no problem. except of the usual "easy to forget copy" 
in Dides case. Hmm, maybe this effect is really hidden, with what-dir 
beeing a function. Easy to expect it copies.

yes that's what I mean, nothing wrong with rebol, but who guesses 
that this returns a really vulnerable path

Everyone who knows Carls ways of ssaving space. Although, i agree 
:)

:-)

but then Carl should write something about stylerules to add to every 
function documentation which states whether it's copying things or 
not - sometimes it's mentioned but like in 'what-dir 's case not 
- so either better styleguide or these things should be implemented 
the safe way

its easier to write when its copied..

what do you mean ? (you don't need to copy yourself - thus saving 
a word?)

No, if there isnt mentioned "it returns a copy" better expect it 
does not..

WHich is rarely, so it is easier to add the few "it copies" then 
the lot "it does not"

ok, only problem I have is that in real world situations one can't 
think about everything and starting to copy everything everywhere 
just to be safe is no solution

I'm thinking more in terms of some normal person (if there is something 
like that) and to me it seams quite a burden to think even about 
such tiny details

Dont take me serious, i am sarcastic! Although i don't know a good 
general solution for this copy-thing.

and in my case it was even worse as I didn't know what happend until 
I stared to examine a outside script pretty closely and step by step 
following what it does

yes I understand - I just don't know a good solution either

maybe it should really be a docu-rule. Forth has some flag-letters, 
like M: multitasking-impact etc. We could have C: copies/not, calls 
wait, what else?

( i am away, cu)

bye