That works! And yes, was close to what I was doing (but better).
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Saturday, May 27, 2000 2:25 AM
To: [EMAIL PROTECTED]
Subject: [REBOL] refinements Re:(7)
Hi, is this close to what you wanted to have?
f1: function [/va /vb /vc][path-list r-word][
path-list: to path! 'f2
foreach r first :f1 [
if all [
refinement? r
r <> /local
get r-word: bind to word! r 'r-word
] [
insert tail :path-list r-word
]
]
print ["Calling path:" mold :path-list]
]
Regards
Ladislav
> f1: function [/va /vb /vc][param-list param-values r path-list][
> param-list: make block! []
> param-values: make block! []
> foreach r first :f1 [
> if (refinement? r) and (r <> /local) [
> append param-list r
> append param-values get bind to-word r 'param-list
> ]]
> path-list: join [f2] param-list
> print ["Calling path:" mold to-path path-list]
> do to-path path-list
> ]
>
> f2: function [param-list][va vb vc][
> foreach r param-list [
> print r
> ]
> ]
>
> >> f1/vb
> Calling path: f2//va//vb//vc
>
> Doesn't work (yet).
>
> - Michael Jelinek
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 26, 2000 10:10 AM
> To: [EMAIL PROTECTED]
> Subject: [REBOL] refinements Re:(5)
>
>
> Funny that you mention it. It slipped from our lists, but we do
need to
> evaluate dynamically built refinement blocks. E.g:
>
> do to-path [insert part] a b
>
> Should be the same as:
>
> insert/part a b
>
> Comments?
>
> -Carl
>
>
> At 5/26/00 08:55 AM -0700, you wrote:
> >Oh yes, I've considered restructuring things, but the current
arcitecture
> is
> >the one that best suits all of my needs (the best one that I
have been able
> >to think of, anyway). Specifically, when I define a function
element in an
> >object, that function does nothing more than to call another
function (not
> >defined as part of the object) to do the work. For example:
> >
> >door-man: make object! [
> > vocab1: "hello"
> > vocab2: "world"
> > speak: func [][say-greeting self]
> >]
> >
> >say-greeting: func [idiot][
> > print [idiot/vocab1 idiot/vocab2]
> >]
> >
> >door-man/speak
> >
> >This simple example is neat and clean. The messy part is when I
also have
> to
> >pass-through refinements. Then I not only have to keep both
functions in
> >sync with the refinement list, but I also have to keep the 'if
statements
> in
> >sync. I've been doing that with the assumption that I only
specify a single
> >refinement at a time. To save me just that much more work, it'd
be nice to
> >have some automatic way of passing the refinements.
> >
> >I have considered passing the refinements as a block, and even
the idea of
> >defining them as an object (within the pass-through function)
is appealing.
> >This involves looping to get the refinement! values from the
first block of
> >the function. But the only way I know how to get the value of a
refinement!
> >type is to cast it as a word!, then use 'get, then bind it to
the current
> >context (ick). It seems like there should be a way to evaluate
a
> refinement!
> >type directly. That would make me happy.
> >
> >- Michael Jelinek
> >
> >-----Original Message-----
> >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> >Sent: Friday, May 26, 2000 2:30 AM
> >To: [EMAIL PROTECTED]
> >Subject: [REBOL] refinements Re:(3)
> >
> >
> >[EMAIL PROTECTED] wrote:
> >> But (unless I don't get it, here) this uses exactly what I am
trying to
> >avoid using: an 'if statement for each possible refinement. I
agree it's
> >easier and more straight forward, but it also creates more work
to maintain
> >(such as when refinements are added to a function). Since I use
this
> >"pass-through of refinements" idea as a common practice in my
program, the
> >added maintenance adds up.
> >
> >It's only one 'if per refinement that's to be passed through.
It avoids
> >multiple combinations of 'ifs. For each refinement added, it's
only one
> >extra 'if to write. I believe that this approach is only a
small price to
> >pay.
> > If you're commonly passing refinements through to
subfunctions,
> consider
> >restructuring your software. It may be better to use a
different approach,
> >perhaps using objects?
> >
> >YMMV. :-)
> >
> >Andrew Martin
> >ICQ: 26227169
> >http://members.xoom.com/AndrewMartin/
> >-><-
> >
>
>
