World: r3wp

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

This is what I called gotchas.

how do you test for a function that returns nothing? I want to DO 
a script, and check if there was an error, but the script might sometimes 
not return anything

!>>error? [()]
== false

!>>unset? ()    
== true

!>>attempt[() true]
== true
!>>attempt[1 / 0 true] 
== none

if error? set/any 'err try [do %script.r][print mold disarm err]

MichaelB: about the path problem in request-dir, it's a bug in the 
code.


The simple solution is to patch this line (in request-dir func at 
the end of the script :
	if not all [keep path] [path: any [where what-dir]]
like this :
	if not all [keep path] [path: copy any [where what-dir]]

the 'path word is local to ctx-req-dir context and the Rebol path 
must not be changed by it. It's up to the "user code" to change it 
if he wants to.

But I agree that Rebol should check if path is "complete" (trailing 
"/") before using it in read/save/load/... functions