At 2/18/2008 10:10 AM, Ken Martin wrote:
>
> FUNCTION(SET_VAR2 varname)
>SET_VAR1(${varname})
> ENDFUNCTION(SET_VAR2)
And you should live with that. And like it dang it! :)
I'm linking it but I'm kinda surprised you wouldn't go for something
beautiful *and* eternally classic like a new ma
> Would
> RAISE_SCOPE(var1 var2 ... varN)
> be better ?
> Why was the syntax changed from that to
> RAISE_SCOPE(varname value) ?
> (which was basically a set() and that's why converted to
> set(... PARENT_SCOPE) )
The old syntax of raise scope often required that you first set the value of
the va
> FUNCTION(SET_VAR1 varname)
>SET(${varname} "There's science to do" PARENT_SCOPE)
> ENDFUNCTION(SET_VAR1)
>
> FUNCTION(SET_VAR2 varname)
>SET_VAR1(${varname})
> ENDFUNCTION(SET_VAR2)
>
> SET_VAR2(foo)
> MESSAGE("${foo}")
>
> Obviously foo is not set, since it is now set in SET_VAR2 scop
On Feb 17, 2008 6:01 AM, Pau Garcia i Quiles <[EMAIL PROTECTED]> wrote:
>
> As a reminder, here comes the nomenclature in Ruby:
>
> Scope Prefix Example
> - -- ---
> global variable $$global
> instance variable @
Quoting Brandon Van Every <[EMAIL PROTECTED]>:
I have to admit, PARENT_SCOPE nomenclature bugs me. I don't know of
any mainstream programming language that explicitly asks me to think
about scope when setting a variable.
Ruby asks. But it does so in a so nicely and clear way that you
actual
On Feb 16, 2008 3:48 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote:
>
> Any opinion whether RAISE_SCOPE/PARENT_SCOPE should propagate to the parent
> directory if it's used outside a function ?
What if I do want a variable to "propagate up" through nested
functions functions, but I don't want a
Sebastien BARRE wrote:
OK, back to PARENT_SCOPE. Well, Tcl/Tk has 'upvar' (which RAISE_SCOPE
was inspired from), *and* 'global', which would pretty much declare
variables inside a procedure/function to be of the "global scope"
nature. I don't really like any of them. If I had to give a (crazy)
At 2/16/2008 03:48 PM, Alexander Neundorf wrote:
Would
RAISE_SCOPE(var1 var2 ... varN)
be better ?
Why was the syntax changed from that to
RAISE_SCOPE(varname value) ?
(which was basically a set() and that's why converted to
set(... PARENT_SCOPE) )
Sorry, I missed the fact that RAISE_SCOPE ha
On Saturday 16 February 2008, Sebastien BARRE wrote:
Hi Sebastian,
...
> Hey guys,
...
> Obviously foo is not set, since it is now set in SET_VAR2 scope. Bummer.
> So now I have to do things like this:
>
> FUNCTION(SET_VAR2 varname)
>SET_VAR1(varname_proxy)
>SET(${varname} ${varname_proxy
At 2/16/2008 02:13 PM, Alexander Neundorf wrote:
>
> I don't mean to remove the SET(PARENT_SCOPE) feature, where the main
> purpose is to set a global variable from within a function.
> But if SET( ... PARENT_SCOPE) is called outside a function, the effect is
> that the variable is set in the par
10 matches
Mail list logo