---- On Wed, 10 May 2006, Gregg Irwin
([EMAIL PROTECTED]) wrote:
> Not true; path notation can be used on blocks just as easily.
The
> difference being that normally you use word! values, rather
than
> set-word! values, to name elements (for easier access).
Of course, and once again, Mr. Irwin, How are your reading
comprehension skills?
I stated (quoting myself)
Ordinary blocks only allow for IMPLICIT naming of elements
contained therein, which requires one to
1) remember their sequence
2) use any of these for retrieval:
ordinal phrases (first, second, third ... [ ])
pick phrases (pick [ ] n) *
select phrases (select [ ] 'selector-word)
path phrases ([ ] /n) *
extract phrases (extract [ ] n) and (extract/index [ ] n m) *
* where n = any integer; m = any integer
Do you SEE that English phrase there 'path phrases'? Hmm. I
wonder what it means? Oh, yeah, ...
you can use path phrases for retrieval of elements contained
within ordinary blocks.
Now onto your examples.
1) these examples fail BECAUSE it requires you to remember their
sequence.
[a]
>> block: [name "Gregg" phone #208.461 name "Other Smarter Gregg
"]
== [name "Gregg" phone #208.461 name "Other Smarter Gregg"]
>> block/name
== "Gregg"
>> block/name
== "Gregg"
>> block/name
== "Gregg"
>> ; no matter how many times we try, we can't reach the "Other
Smarter Gregg"
[b]
block: [name "Gregg" phone #208.461.... <tag> {you think "it
worked!" but we can only access THIS ONE. IMPLICIT NAMING
requires extra work}<tag> "see, it's IMPLICIT and therefore
doesn't work unless you remember the sequence"]
>> block: [name "Gregg" phone #208.461.... <tag> {you think "it
worked!" but we can only access THIS ONE. IMPLICIT NAMING requir
es extra work}<tag> "see, it's IMPLICIT and therefore doesn't wo
rk unless you remember the sequence"]
== [name "Gregg" phone #208.461.... <tag> {you think "it worked!
" but we can only access THIS ONE. IMPLICIT NAMING requires extr
a w...
>> block/<tag>
== {you think "it worked!" but we can only access THIS ONE. IMPL
ICIT NAMING requires extra work}
>> block/<tag>
== {you think "it worked!" but we can only access THIS ONE. IMPL
ICIT NAMING requires extra work}
>> block/<tag>
== {you think "it worked!" but we can only access THIS ONE. IMPL
ICIT NAMING requires extra work}
>> ; no matter how many times we try, we can't reach the other
<tag> unless we REMEMBER the sequence
>> fourth block
== #208.461....
>> ;that's not it
>> fifth block
== <tag>
>> ;that's not it
>> seventh block
== <tag>
>> ;that's not it
>> eighth block
== {see, it's IMPLICIT and therefore doesn't work unless you rem
ember the sequence}
>> ; finally THAT's IT!
BUT, if you
>> block: [name1: "Gregg" phone1: #208.461 name2: "Other Smarter
Gregg"]
== [name1: "Gregg" phone1: #208.461 name2: "Other Smarter Gregg"
]
>> Smarter-Gregg-Block: make object! block
>> Smarter-Gregg-Block/name2
== "Other Smarter Gregg"
NOW, you can use path retrieval on EXPLICIT aspects of the
prototype ("object") using path-words
AGAIN, implicit naming requires one to perform an EXTRA step as
the ordinary Gregg so inadvertently but adroitly points out
here:
OG> Indirection for path elements:
OG> >> field: 'phone
OG> == phone
OG> >> block/:field
OG> == #208.461....
SEE the extra step? It's ----------> field: 'phone
BUT this fails as soon as you have MORE THAN ONE implicit name,
e.g.,
>> block: [name "Gregg" phone #208.461 name "Other Smarter Gregg
" phone: #555-smarter]
== [name "Gregg" phone #208.461 name "Other Smarter Gregg" phone
: #555-smarter]
>> field: 'phone
== phone
>> block/:field
== #208.461
>> block/:field
== #208.461
>>
>>
>> block/:field
== #208.461
>> ; no matter how many times we try, we can't reach the phone o
f the Other Smarter Gregg
________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
--
To unsubscribe from the list, just send an email to
lists at rebol.com with unsubscribe as the subject.
