Bug! path! in objects don't behave the same as path! outside object

[ p: does [print "function 'p in 'base"] [ ]

[ p: first [base/p] [ ]

== base/p

function 'p in 'base

== base/p

function 'p in 'base

== base/p The above is incorrect, I believe. The result of the above should be the result of base/p: function 'p in 'base _not_ the path: base/p Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/ http://members.xoom.com/AndrewMartin/

Which parallel case involving paths are you thinking of? Here is an example case that does not involve objects at all and behaves exactly the case you attribute to objects:

'p in 'base.

[base] ] ]

== base

== base/p When you create the object (or in my example the function) the expression first [base/p] is evaluated. It evaluates to the path base/p

== path! base/p is a value of type path! This value, base/p, is referenced by p in your make object! example. If you want REBOL to instead assign p as a reference to the value that the path evaluates to, you must tell REBOL that:

'p in 'base. i.e. derived: make object! [ p: first reduce [base/p] ]

;- Elan [ : - ) ] author of REBOL: THE OFFICIAL GUIDE REBOL Press: The Official Source for REBOL Books http://www.REBOLpress.com visit me at http://www.TechScribe.com

Hi, Elan. I agree with everything up to here:

path evaluates to, you must tell REBOL that:

Unfortunately, that doesn't work:

function 'p in 'base ** Script Error: p needs a value. ** Where: p: first reduce [base/p] I'd like 'p in 'derived to be a path!, which refers to 'p in 'base. Like I can do with 'p outside of derived. Watch closely:

== base/p

function 'p in 'base == unset!

== path!

function 'p in 'base ** Script Error: probe is missing its value argument. ** Where: probe p

base/p == base/p Now if this behaviour outside an object were implemented inside an object, then it would be very easy to write objects that inherit behaviour, and the storage cost wouldn't involve copying functions into every object. I think that would be very nice behaviour. I can also show that it's fault in objects because:

== base/p

make object! [ p: base/p ]

== base/p

function 'p in 'base Andrew Martin Breaking new paths... ICQ: 26227169 http://members.nbci.com/AndrewMartin/ http://members.xoom.com/AndrewMartin/

1. Word evaluation: a) word references a path that evaluates to a string.

== base/p

== base/p

== "'p in 'base." b) word references a path that evaluates to a path:

== derived/p

== derived/p

== base/p In both cases when REBOL evaluates a word and the word evaluates to a path, then REBOL returns the value that is referenced by the path. It stops dereferencing values at the second level as demonstrate by r. The evaluator return base/p and did not continue to dereference the path base/p. Compare to: 2. Path evaluation:

== base/p Re: 1. (a and b) When REBOL evaluates a word, and the returned value is a path, then REBOL returns the value referred to by that path. Re: 2. When REBOL evaluates a path, then it returns the value that path is associated with. Unlike case 1., the path returned by evaluating the top-level path is not dereferenced. 3. In both cases 1. and 2. if the returned value is a function, then that function is evaluated and the value resulting from evaluating the function is returned. So what you are dealing with here is an exception that REBOL evaluator makes for words, when those words evaluate to paths. You can say that with respect to this behavior the REBOL evaluator works something like this: evaluate: func [something [any-type!]] [ if value? 'something [ either all [ word? get 'something path? get get 'something ] [ return get get 'something ][ return get 'something ] ] return print "unset" ]

== "'p in 'base."

== base/p Note that this really has nothing to do with objects. You can do the same thing with blocks:

== [p "'p in 'block"]

== "'p in 'block" Word is assigned a path:

== block/p When the REBOL evaluator discovers that the word p is referencing a path, then the path is dereferenced as well:

== "'p in 'block" But when REBOL is evaluating a path (this time associated with a block) then unlike when evaluating a word, the evaluation is not repeated for the referenced path:

== [p block/p]

== block/p In short, REBOL is consistent with respect to the distinction it makes between evaluating words and evaluating paths. The way REBOL treats path is not specific to objects. Hope this helps, ;- Elan [ : - ) ] author of REBOL: THE OFFICIAL GUIDE REBOL Press: The Official Source for REBOL Books http://www.REBOLpress.com visit me at http://www.TechScribe.com

then the path is dereferenced as well:

then unlike when evaluating a word, the evaluation is not repeated for the referenced path:

between evaluating words and evaluating paths. The way REBOL treats path is not specific to objects. I agree. But it would be very, very nice if the natural value of a path! is the dereferenced value. So that a path! value operates like a function! value does. Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/ http://members.xoom.com/AndrewMartin/